@lunaar/mcp-server

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct task or product category (jewelry, glasses, garments, product shots, food, 3D models, etc.), with clear boundaries. The operations management tools are separate from generation tools, avoiding confusion.
Naming Consistency5/5
All tools follow a consistent 'lunaar_<descriptive_verb_noun>' pattern with snake_case, making the purpose immediately clear. No mixing of conventions.
Tool Count5/5
14 tools cover a wide range of image generation and manipulation tasks without being overwhelming. Each tool serves a distinct purpose, and the count feels appropriate for the server's scope.
Completeness4/5
The tool surface covers core workflows for try-on, product shots, food visuals, 3D generation, AR, and upscaling. Minor gaps exist (e.g., no general background removal or editing tool), but the set is largely complete for its intended domain.
Average 3.8/5 across 14 of 14 tools scored. Lowest: 3/5.
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 is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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?
Mentions anatomy-aware fit and cost (10 credits per call), but lacks detail on side effects, idempotency, or required permissions.
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?
Short single sentence plus credit note, well front-loaded. Could be slightly more informative without losing conciseness.
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?
With 3 parameters and no output schema, the description omits expected output format, image requirements, and error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% and description provides no additional meaning for the undocumented parameters (personImagePath, glassesImagePath). Does not compensate for low 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?
Clearly states the tool places glasses on a model's face with anatomy-aware fit, distinguishing it from related tools like lunaar_jewelry_tryon or lunaar_studio_tryon.
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?
No guidance on when to use this tool versus alternatives, nor any prerequisites or constraints for images.
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?
Discloses cost (5 credits) and synchronous behavior. With no annotations, description carries full burden; it lacks details on destructive actions, auth requirements, rate limits, or file constraints, but provides some useful behavioral info.
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?
Two sentences are concise and front-loaded with key info. Each sentence adds value, though structure could be improved with bullet points for clarity.
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 4 parameters (2 required) and no output schema, the description does not cover return details (e.g., URL format), file size limits, processing time, or error conditions. Incomplete for an upload/conversion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% so description must explain parameters. It only mentions 'GLB' and optional 'USDZ + thumbnail', without describing the required 'title' or how 'glbFilePath' is used (e.g., it's a path to an existing file). Inadequate parameter guidance.
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?
Clearly states 'Upload an existing GLB ... get a public AR-viewer URL', specifying the action and outcome. However, it does not explicitly differentiate from siblings like lunaar_image_to_3d (which creates 3D models from images) or other tryon tools, so purpose is clear but sibling distinction is implicit.
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?
Mentions credits per call and sync return, giving basic usage context. No explicit when-to-use or when-not-to-use, and no alternatives listed among siblings, so guidance is minimal.
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 provided, and the description only mentions credit costs per mode. It fails to disclose other behavioral traits such as authentication, rate limits, or error handling, leaving the agent with insufficient behavioral context.
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 one sentence stating purpose and credit costs. It is front-loaded with the main verb and resource, but could benefit from slightly more structure to improve readability.
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 complexity (6 parameters, 4 enums) and no output schema, the description lacks complete context. It does not describe return values, success criteria, or common use cases, making it insufficient for reliable tool invocation.
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 50%, with some parameters documented in the schema (e.g., gender, aspectRatio). The description adds credit cost context but does not explain the meaning or usage of parameters beyond what's in the schema.
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 composites jewelry onto a model or surface, with specific credit costs per display mode. This distinguishes it from sibling tools like lunaar_glasses_tryon by focusing on jewelry.
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 for jewelry try-on with different modes and credit costs, but does not explicitly state when to use or avoid this tool versus alternatives like lunaar_studio_tryon.
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 present, so description must cover all behavioral aspects. It only states the action and credit cost, omitting details like return format, failure modes, or specific image requirements (e.g., lighting, pose).
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?
Two sentences, zero waste. Front-loaded with the core action and credit cost. Every word earns its place.
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?
No output schema and description does not mention return values (e.g., which measurements, units, or confidence). Also lacks details on validation or error handling, leaving the agent underinformed about what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter descriptions. The tool description adds no extra parameter meaning beyond what the schema already provides, so baseline 3 applies.
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 verb 'Extract' and the resource 'anatomical measurements (chest, waist, hip)', and specifies the input (single full-body photo). It effectively distinguishes from sibling tools that focus on try-on, sketches, or product shots.
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 indicates the input type (full-body photo) and mentions credit cost, but lacks explicit guidance on when to use versus alternatives, no prerequisites or exclusions.
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?
Discloses cost (15 credits) and refund policy, but with no annotations provided, other behavioral traits like authentication, rate limits, or side effects are unaddressed. The description adds some value but is incomplete.
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?
Three sentences with zero fluff. Each sentence provides essential information: function, output, and cost/refund. Ideal conciseness.
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 12 parameters, no output schema, and no annotations, the description omits key details like parameter roles, error scenarios, and output format beyond URL. Incomplete given tool complexity.
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 83%, so the schema already documents most parameters. The description does not add additional meaning beyond what the schema provides, earning a baseline of 3.
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 verb 'convert' and resource 'sketch to photoreal render', specifies applicable types (interior/exterior/kitchen), and distinguishes from sibling tools like lunaar_product_shot.
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?
No guidance on when to use this tool versus alternatives such as lunaar_product_shot or lunaar_food_visual. Does not provide context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Mentions 'recent' and 'current API key' but does not detail pagination behavior, rate limits, or how optional filters affect results. Adequate for a non-mutating list, but leaves gaps.
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?
Two concise sentences front-loaded with the action and use cases. No wasted words.
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 list tool with 4 optional parameters and no output schema, the description covers basic purpose but fails to explain filtering/pagination or return value format. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation for any of the 4 parameters. The agent gets no guidance on how 'page', 'type', 'status', or 'pageSize' affect the tool's behavior.
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?
Clearly states the verb 'list' and resource 'operations for the current API key'. Distinguishes from sibling 'lunaar_get_operation' by implying a list vs single item retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions use cases: picking up a forgotten operationId or auditing recent calls. Provides context for when to use, but does not explicitly exclude when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses credit costs and mode-specific behavior (e.g., 'Kids' uses AI-generated child model, no PersonImage). However, it does not mention failure modes, rate limits, or the response structure, leaving gaps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise given the complexity, with each sentence adding distinct information (modes, credits, parameter conditions). It is front-loaded with the core purpose. Minor improvements could include bullet points for clarity, but it remains 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?
With 28 parameters, no output schema, and moderate schema coverage, the description provides essential mode-specific context but omits details on return format, error handling, or parameter interrelationships beyond mode requirements. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (36%), but the description adds value by explaining mode dependencies and required parameters (e.g., for 'Kids': kidsGender, kidsAgeRange, kidsProductCategory). However, many parameters (e.g., fitType, dressLength) are not elaborated beyond the schema, and the description does not fully compensate for the coverage gap.
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 identifies the tool as 'Virtual try-on' and enumerates five specific modes with distinct credit costs and requirements. This specificity distinguishes it from sibling tools like lunaar_jewelry_tryon and lunaar_glasses_tryon, which cover different domains.
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 by detailing modes (e.g., 'SingleItem', 'Combo') but does not explicitly compare this tool to alternatives or provide scenarios where it is preferred. Some mode-specific guidance is given (e.g., 'Kids' requires certain parameters), but no when-to-use or when-not-to-use statements are present.
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 credit cost, refund policy, and incompatibility with Summer/Kids items, which adds value. However, it omits other behavioral traits like processing time, idempotency, or side effects on the original item, leaving some gaps.
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 sentence followed by a short note, with no wasted words. It front-loads the core action and immediately follows with key constraints. Every sentence serves a purpose.
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's complexity (a generation tool with credits and constraints), the description covers prerequisites, exclusions, and cost. However, it lacks any description of the output (e.g., format, what is returned) and does not provide an example. This leaves the agent uncertain about how to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% with only parentEntityId having a description. The tool description improves this by clarifying that parentEntityId is 'the entityId returned by lunaar_studio_tryon—NOT the operationId.' For poseTypes, the description mentions the count (1-3) but does not explain the enum values, so the schema's enum alone provides the meaning. Overall, the description partially compensates for missing schema 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 'Generate 1-3 alternate-pose variants of a previously rendered Studio item,' which provides a specific verb and resource. It also distinguishes from sibling tools like lunaar_studio_tryon by explicitly requiring a previously rendered item, clarifying the tool's role in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit context on when to use (after rendering a Studio item) and when not to use ('Not available for Summer or Kids items'). It also mentions credit cost and auto-refund policy. However, it does not suggest alternative tools for excluded cases, preventing full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It states the AI analyzes the meal, adapts the environment, and never redesigns the meal itself. It also notes credit cost and latency. However, it does not clarify if the operation is read-only or destructive, nor does it describe the output format or how the result is returned.
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 three sentences, efficiently covering purpose, mood options, and key constraints. No redundant or extraneous information is present. It is well-structured and front-loaded with the main action.
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 (six moods, three parameters) and lack of output schema, the description covers purpose, parameters, cost, and latency. However, it omits the output format (e.g., image URL or base64) and how the result is accessed, which would be valuable for an AI agent. Overall, it is fairly complete but could include return value details.
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?
The description adds significant meaning beyond the input schema. Each mood value is explicitly described (e.g., 'studio=white background menu shot'), and constraints for imagePath (format and size) and aspectRatio (defaults to auto) are provided. The schema covers 67% of parameters with descriptions, but the description enriches understanding of all three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: turning a casual food photo into a premium food photograph. It is distinct from sibling tools (e.g., lunaar_jewelry_tryon, lunaar_product_shot) by focusing specifically on food images. The six mood options are detailed, making the tool's capability unambiguous.
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 provides usage context (list of moods and their styles) but does not explicitly specify when to use this tool versus alternatives. It lacks when-not conditions or direct comparisons to siblings. The credit cost and latency are mentioned, which aids selection, but overall guidance is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates a read operation ('inspect') but does not disclose potential traits such as rate limits, authentication needs, or response format. For a simple get by ID, the transparency is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no unnecessary words, front-loaded with the primary action.
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 simple get operation with no output schema, the description covers the core purpose and usage. Minor gap: does not explicitly describe the return value, but the context of polling implies status information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the only parameter (operationId). The description does not elaborate on the parameter beyond its name. While the name is self-explanatory, with 0% coverage, the description should offer more detail. Baseline for 0% is low, but 1 param prevents a 1.
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?
Clearly states 'Inspect any operation by id', which is a specific verb and resource. Distinguishes from sibling lunaar_list_operations which lists operations, and mentions a specific use case (Image-to-3D run).
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?
Explicitly specifies when to use: 'when an earlier tool returned a non-terminal status, or to poll a long-running Image-to-3D run'. Provides clear context and implies not for other purposes.
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?
Discloses credit consumption and fallback behavior for open_interior. With no annotations, description carries full burden but omits operational details like parallelism, rate limits, or response format.
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?
Single paragraph that front-loads purpose and credit cost, then enumerates variant types. Efficient but could benefit from bullet points for clarity.
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?
Covers main function, variant details, credit cost, fallback, and dimension requirements. Lacks output description but no output schema exists. Sufficient for agent use.
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?
Adds significant meaning to variantTypes by explaining each type and to dimension parameters for scale_reference. Schema coverage is only 50%, so description compensates with context for half the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it generates variants of a previously rendered product shot, listing specific variant types and explaining their behaviors. Distinguishes from sibling tool lunaar_product_shot by requiring a parent.
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?
Provides context that it requires a parent shot and explains when to use scale_reference with dimensions. Does not explicitly exclude alternatives or state when not to use, but the sibling context and description make usage clear.
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?
Discloses cost (10 credits), latency (2-4 minutes), and asynchronous behavior (polling). This compensates for lack of annotations. However, does not detail if the tool modifies any state or what happens to uploaded images.
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?
Two sentences efficiently convey purpose, cost, latency, and fallback. No redundant information. Front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers essential behavioral aspects: input (photo), output (GLB + video), cost, timing, and error handling fallback. Missing details about required image characteristics (e.g., background, size) but overall 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?
The description clarifies that the imagePath parameter should be a 'single product photo', adding context beyond the schema. The targetHeightCm parameter is already well-described in the schema. The description partially compensates for the 50% 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?
Clearly states that the tool generates a GLB 3D model and spinning preview video from a single product photo. This distinguishes it from sibling tools like lunaar_jewelry_tryon or lunaar_product_shot which focus on different tasks.
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?
Mentions credit cost and latency. Provides explicit alternative: use lunaar_get_operation if polling window exceeded. However, does not specify when not to use this tool (e.g., for non-product photos or non-3D needs).
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?
No annotations provided, so description carries full burden. It discloses key behaviors: cost, response types (200 vs 202+ poll), and that it works on completed operations. No hidden behaviors mentioned, but sufficient for a simple 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?
Two sentences, no wasted words. Critical info (purpose, cost, response handling) is front-loaded. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple signature (1 param, no output schema, no annotations), description covers purpose, cost, and response behavior adequately. Missing details on error cases or output format, but not critical for a straightforward upscale tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with clear description. Description reinforces that operationId must be from a completed run but adds no new meaning beyond the schema. Baseline 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?
Description clearly states verb ('re-render') and resource ('completed AI operation') at higher resolution. It distinguishes from sibling tools which are for different AI operations (try-on, sketches, etc.).
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?
Provides cost (5 credits) and response behavior (inline or queued), giving agents clear usage context. However, it lacks explicit when-to-use vs alternatives or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses auto-detection of product category, four generation modes, credit cost (10 credits), latency (15-30s), and refund policy on provider failure. This is comprehensive for a creation 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?
Two sentences cover purpose, mode details, and operational constraints (credits, latency, refund). No redundant or extraneous text. Front-loaded with key 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 3 parameters and no output schema, the description covers all inputs, behavior, constraints, and special outcomes (refund on failure). Complete for a generation tool.
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 100%, so baseline is 3. Description adds value by explaining the meaning of each mode beyond schema enums, and clarifies the auto-detect behavior for mode. Aspect ratio auto-pick is also explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: 'Turn a casual product photo into a premium e-commerce shot.' It uses specific verb phrase and resource, and distinguishes from siblings focused on specific product types like jewelry or glasses.
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?
Description explains when to use each of the four modes, but does not explicitly contrast with sibling tools like lunaar_product_shot_variants or provide when-not scenarios. Nonetheless, the mode selection provides clear usage context.
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:

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

Score Badge

Copy to your README.md:

[![lunaar-mcp-server MCP server](https://glama.ai/mcp/servers/Group-Taiga/lunaar-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Group-Taiga/lunaar-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/Group-Taiga/lunaar-mcp-server'

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