Atlas Cloud MCP Server (Image / Video / LLM APIs)

Server Quality Checklist

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

Latest release: v1.3.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between atlas_quick_generate and the specific generation tools (atlas_generate_image, atlas_generate_video). The quick_generate tool serves as a convenience wrapper that could cause confusion about when to use it versus the more explicit tools, though descriptions clarify its role as a fallback. Other tools like atlas_list_models, atlas_get_model_info, and atlas_search_docs have clear, non-overlapping functions for discovery and documentation.
Naming Consistency5/5
All tool names follow a consistent 'atlas_' prefix with snake_case naming, using descriptive verb_noun patterns (e.g., atlas_chat, atlas_generate_image, atlas_list_models). This uniformity makes the tool set predictable and easy to navigate, with no deviations in style or convention across the nine tools.
Tool Count5/5
With 9 tools, the count is well-scoped for the server's purpose of accessing image, video, and LLM APIs. It covers core operations like generation (chat, image, video), model discovery (list, info, search), task management (get_prediction), and utilities (upload_media), without being excessive or lacking essential functionality.
Completeness5/5
The tool set provides complete coverage for the domain, including CRUD-like operations for generation tasks (create via generate tools, read via get_prediction), comprehensive model discovery and documentation (list_models, get_model_info, search_docs), and necessary utilities (upload_media). There are no obvious gaps; agents can handle full workflows from model selection to result retrieval.
Average 4.4/5 across 9 of 9 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 27 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
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.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a safe, read-only, idempotent, and open-world operation. The description adds context by specifying that it fetches OpenAPI schema and generates documentation with cURL examples, which provides useful behavioral details beyond the annotations. However, it doesn't mention potential rate limits, authentication needs, or error conditions.
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-structured with clear sections (purpose, args, returns, examples) and uses bullet points for readability. It's appropriately sized for the tool's complexity, though the 'Returns' section is slightly verbose. Most sentences add value, but there's minor repetition in the examples.
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's moderate complexity (single parameter, read-only operation) and rich annotations, the description is mostly complete. It details the output format (markdown with specific content) and provides examples. However, without an output schema, it could benefit from more explicit return structure details or error handling information.
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, fully documenting the single 'model' parameter. The description adds minimal value beyond the schema by listing example model IDs and noting the parameter is required, but doesn't provide additional syntax, format details, or constraints. 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.
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 purpose with specific verbs ('Get detailed information', 'fetches', 'generates') and identifies the resource ('a specific Atlas Cloud model'). It distinguishes this from sibling tools like atlas_list_models (which lists models) and atlas_get_prediction (which runs predictions), making the scope and differentiation explicit.
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 implies usage context by specifying what information is returned (metadata, pricing, schema, examples), suggesting it's for understanding model capabilities before use. However, it doesn't explicitly state when to use this tool versus alternatives like atlas_list_models (for browsing) or atlas_search_docs (for documentation), 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide basic hints (non-readOnly, non-destructive, non-idempotent, openWorld), but the description adds valuable context: it specifies the API format ('OpenAI-compatible'), mentions default values for temperature and top_p, and describes the return structure ('including generated message, token usage, finish reason'). This goes beyond what annotations convey about the tool's behavior.
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 well-structured with clear sections (purpose, Args, Returns, Examples), front-loading the core functionality. Every sentence earns its place by providing essential information without redundancy. The examples are concise yet illustrative of common use cases.
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 tool with 5 parameters, 100% schema coverage, and no output schema, the description provides good context: it explains the API format, parameter defaults, and return structure. However, it doesn't mention potential errors, rate limits, or authentication requirements that would be helpful given the openWorldHint annotation. The examples help but don't fully compensate for missing output schema.
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?
With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description provides examples that illustrate parameter usage but doesn't add significant semantic meaning beyond what's in the schema descriptions. The baseline of 3 is appropriate since 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 ('Send a chat completion request') and resource ('to an LLM model via Atlas Cloud API'), with explicit format details ('OpenAI-compatible format'). It distinguishes this chat-focused tool from siblings like image/video generation or model listing tools by specifying its chat completion purpose.
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 through the OpenAI-compatible format mention and examples, but doesn't explicitly state when to use this tool versus alternatives like 'atlas_quick_generate' or 'atlas_get_prediction'. No guidance is provided about prerequisites, error conditions, or specific scenarios favoring this tool over siblings.
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?
Annotations already cover key behavioral traits (read-only, non-destructive, idempotent, open-world). The description adds useful context about the return format ('Markdown-formatted list of models grouped by type') and optional filtering, but does not disclose additional aspects like rate limits, authentication needs, or pagination behavior. No contradiction with annotations.
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 well-structured and front-loaded with the core purpose, followed by clear sections for Args, Returns, and Examples. Every sentence earns its place by providing essential information without redundancy, making it easy to scan and understand.
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's low complexity (one optional parameter), rich annotations, and 100% schema coverage, the description is mostly complete. It explains the purpose, usage, and return format. However, without an output schema, it could benefit from more detail on the return structure (e.g., specific fields like pricing units).
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% (the single parameter 'type' is fully documented in the schema with enum values and description). The description adds minimal value beyond the schema by providing examples of parameter usage, but does not explain semantics or constraints not already in the schema. Baseline 3 is appropriate given 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 ('List all available models') and resource ('on Atlas Cloud'), and distinguishes it from siblings like atlas_get_model_info (which gets details for a specific model) and atlas_chat/atlas_generate_image (which use models rather than list them). The title reinforces this purpose.
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 optional filtering ('optionally filtered by type') and includes examples for different scenarios. However, it does not explicitly state when NOT to use this tool versus alternatives like atlas_get_model_info (for detailed info on a specific model) or atlas_search_docs (for documentation).
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?
The annotations already indicate this is a safe, read-only, idempotent operation with open-world behavior. The description adds valuable context beyond this by explaining the workflow: it describes statuses ('processing', 'starting', 'completed', 'succeeded'), recommends retry behavior, and provides actionable steps for handling completed results (show URLs, offer download). This enriches the agent's understanding without contradicting annotations.
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-structured and appropriately sized, with clear sections for purpose, usage instructions, and examples. It's front-loaded with the core purpose, and every sentence adds value, such as explaining status handling and result actions. It could be slightly more concise by integrating the example more seamlessly, but overall it's efficient.
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?
Given the tool's moderate complexity (single parameter, no output schema), the description is complete. It covers the purpose, usage context, behavioral details like statuses and retries, and result handling steps. With annotations providing safety and idempotency hints, and the schema fully describing the parameter, no critical information is missing for an agent 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?
The input schema has 100% description coverage, with the parameter 'prediction_id' clearly documented. The description adds minimal extra meaning by noting it's 'returned from a generation request' and providing an example, but this doesn't significantly enhance the schema's information. This meets the baseline of 3 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 tool's purpose with specific verbs ('check the status and result') and resources ('image/video generation task'), distinguishing it from sibling tools like atlas_generate_image or atlas_generate_video which create tasks rather than monitor them. It explicitly mentions it's for use after submitting a generation request, which differentiates it from other tools.
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 ('after submitting a generation request') and when not to use it (if status is 'processing' or 'starting', wait and try again). It also implicitly suggests alternatives by referencing generation requests, which likely come from sibling tools like atlas_generate_image or atlas_generate_video, though it doesn't name them directly.
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?
Annotations already indicate read-only, non-destructive, idempotent, and open-world hints, covering safety and behavior. The description adds useful context by specifying the return format (Markdown-formatted list) and content (models with descriptions, pricing, links), which goes beyond annotations. No contradiction with annotations.
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 well-structured and front-loaded with the core purpose, followed by usage guidelines, parameter info, return format, and examples. Every sentence adds value without waste, making it efficient and easy to parse.
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?
Given the tool's low complexity (1 parameter, 100% schema coverage), rich annotations, and no output schema, the description is complete. It covers purpose, usage, return format, and examples, providing sufficient context for an agent to use the tool effectively without over-explaining.
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 schema fully documenting the single 'query' parameter. The description adds minimal extra meaning by listing examples of what the query can match (e.g., model names, types, providers, tags), but this is largely redundant with the schema. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Atlas Cloud documentation, models, and API references by keyword, specifying it returns matching models with descriptions, pricing, and links. It distinguishes from sibling atlas_get_model_info by noting that tool is for detailed API docs of a specific model, making the purpose specific and differentiated.
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 explicitly provides when to use this tool (search by keyword across models, types, providers, tags) and when not to use it (for detailed API docs of a specific model, use atlas_get_model_info instead), offering clear alternatives and context.
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?
The description adds valuable behavioral context beyond annotations: it discloses that uploaded files are temporary ('may be cleaned up periodically'), warns against abuse ('bulk uploads unrelated to generation tasks may result in API key suspension'), and clarifies the tool's intended scope ('for temporary use with Atlas Cloud generation tasks only'). Annotations provide basic hints (e.g., not read-only, not destructive), but the description enriches this with practical constraints and consequences.
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 well-structured and front-loaded with the core purpose, followed by usage guidelines, important warnings, and examples. Every sentence serves a clear purpose—explaining the tool's role, workflow, constraints, and parameters—with no redundant or unnecessary information.
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?
Given the tool's complexity (a file upload with behavioral constraints) and the absence of an output schema, the description provides comprehensive context: it explains the purpose, usage workflow, supported file types, important limitations, and return value. The annotations cover basic hints, but the description fills in critical details about temporary storage and usage restrictions, making it complete for an agent to use 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?
The schema description coverage is 100%, with the parameter 'file_path' fully documented in the schema as 'Absolute path to the local file to upload'. The description repeats this in the Args section but adds no additional semantic meaning beyond what the schema already provides. This meets the baseline score of 3 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 ('Upload a local image or media file to Atlas Cloud') and the resource ('get a publicly accessible URL'). It distinguishes this tool from siblings by explicitly mentioning its role in workflows with atlas_generate_image, atlas_generate_video, and atlas_quick_generate, which are all sibling tools.
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 ('when you need to provide an image URL... but only have a local file path') and includes a clear workflow with step-by-step instructions. It also specifies when NOT to use it ('Do NOT use this as a permanent file hosting service') and mentions alternatives implicitly by listing the tools that should use the returned URL.
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?
The description adds valuable behavioral context beyond annotations. Annotations indicate it's not read-only, destructive, or idempotent, and has open-world hints. The description clarifies that it submits a request and returns immediately with a prediction ID (asynchronous operation), specifies that model IDs must be exact, and outlines dependencies on other tools for proper usage. No contradiction with annotations exists.
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-structured and appropriately sized, with clear sections (overview, important notes, args, returns, examples). Most sentences earn their place by providing essential information, though some redundancy exists (e.g., repeating atlas_get_model_info usage). It is front-loaded with key details about the asynchronous nature and model ID requirements.
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?
Given the tool's complexity (asynchronous image generation with model-specific parameters), the description is highly complete. It covers purpose, usage workflow, parameter semantics, dependencies on sibling tools, and examples. Although there's no output schema, it clearly explains the return value (prediction ID) and how to use it with atlas_get_prediction, addressing all critical contextual gaps.
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?
With 100% schema description coverage, the baseline is 3. The description enhances this by explaining that 'model' requires an exact ID and must be found via atlas_list_models, and that 'params' are model-specific JSON objects with common examples like 'prompt' and 'image_size'. It also directs users to atlas_get_model_info for full parameter lists, adding practical guidance beyond schema definitions.
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 purpose: 'Generate an image using Atlas Cloud API.' It specifies the exact action (generate), resource (image), and platform (Atlas Cloud API), distinguishing it from siblings like atlas_generate_video (video generation) and atlas_quick_generate (likely a simpler variant).
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 versus alternatives. It instructs to use atlas_list_models to find model IDs, atlas_get_model_info to understand parameters, and atlas_get_prediction to check results. It also warns against guessing model IDs, clearly defining prerequisites and workflow.
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?
The description adds valuable behavioral context beyond annotations: it explains the model search mechanism ('searches for models by keyword matching against model ID, display name, and tags'), clarifies the workflow ('After getting the prediction ID, use atlas_get_prediction to check the result'), and provides failure handling guidance. While annotations cover basic hints (non-readOnly, non-destructive, non-idempotent, openWorld), the description enhances understanding of the tool's operational behavior.
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 well-structured and front-loaded: the first sentence clearly states the core functionality, followed by important usage notes, then parameter explanations with examples. Every sentence serves a purpose - there's no redundant information, and the formatting with bullet points enhances readability without wasting space.
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?
Given the tool's complexity (model discovery, parameter building, task submission) and the absence of an output schema, the description provides excellent contextual completeness. It explains the full workflow from input to result checking, includes failure handling, provides parameter guidance, and references relevant sibling tools. The examples further clarify usage in various scenarios.
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?
With 100% schema description coverage, the baseline is 3, but the description adds meaningful context: it provides concrete keyword examples ('Nano Banana', 'Seedream', 'Kling', 'Vidu', 'Seedance'), clarifies that extra_params can override defaults, and includes multiple usage examples that illustrate parameter combinations. This goes beyond the schema's basic 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 the tool's purpose: 'One-step image or video generation - automatically finds the model by keyword, fetches its schema, builds parameters, and submits the task.' This specifies the verb ('generates'), resource ('image or video'), and distinguishes it from siblings like atlas_generate_image/video by emphasizing the automated model discovery and parameter building process.
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 versus alternatives: 'If this tool fails to find a model, call atlas_list_models first to get the exact model list, then use atlas_generate_image or atlas_generate_video with the exact model ID instead.' It also mentions using atlas_get_prediction to check results, creating a clear workflow with sibling tools.
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?
The description adds valuable behavioral context beyond annotations: it explains the asynchronous nature (returns prediction ID immediately), typical processing time (1-5 minutes), and workflow dependencies (must call other tools first). While annotations cover basic hints (not read-only, not destructive, not idempotent, open world), the description provides practical implementation details that help the agent use the tool correctly.
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?
Well-structured with clear sections: purpose statement, important usage notes, parameter explanations, return information, and examples. Every sentence serves a purpose - no wasted words. The information is front-loaded with critical workflow requirements.
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?
Given the complexity of video generation with model-specific parameters and asynchronous processing, the description provides complete context: explains the full workflow (list models → get model info → generate → check prediction), provides parameter guidance, mentions processing time, and gives concrete examples. This adequately compensates for the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema description coverage, the description adds significant semantic value: explains that model IDs must be exact and obtained from atlas_list_models, provides common parameter examples (prompt, image_url, duration, aspect_ratio), clarifies that parameters vary by model, and directs users to atlas_get_model_info for full schemas. This goes well beyond what the schema provides.
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 ('Generate a video using Atlas Cloud API') and distinguishes it from siblings by mentioning the asynchronous nature and need to use atlas_get_prediction for results. It explicitly differentiates from atlas_generate_image (video vs image) and atlas_quick_generate (which likely has different 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?
Provides explicit guidance on when to use this tool vs alternatives: must use atlas_list_models first to find model IDs, should use atlas_get_model_info to see parameter schemas, and must use atlas_get_prediction to check results. Also mentions typical processing time (1-5 minutes) which helps set expectations.
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:

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

Score Badge

Copy to your README.md:

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

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/AtlasCloudAI/mcp-server'

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