Generate Roblox-ready 3D props from a text prompts GLB + Studio-importable ZIP with measured triangle counts, stud bounding boxes and compliance receipts
Scored across 7 tools
The generation tools overlap: generate_variants is essentially generate_asset with a count, and generate_from_image is a third entry point into the same pipeline. download_asset and get_generation both surface download URLs, so an agent could reasonably fetch the same info two ways. Descriptions do help disambiguate, but boundaries are blurrier than ideal.
Names are all snake_case verb_noun (download_asset, generate_asset, get_generation, list_generations), which is predictable. Minor deviations like generate_from_image (verb_preposition_noun) and validate_roblox (verb_propernoun, which actually validates assets by generation_id) slightly weaken the pattern.
Seven tools cleanly cover an asset-generation pipeline: three generation entry points, a poller, a lister, a validator, and a downloader. Each earns its place and nothing feels padded.
The lifecycle is largely covered: create (text/image/variants), poll status, list history, validate compliance, and download. Minor gaps exist around cancellation/deletion and quota visibility, but agents can work around these.
Get the download URLs for a generated asset: a GLB (game engines, viewers) and a Roblox Studio .zip (OBJ + MTL + texture with bottom-center pivot, imports straight into Roblox Studio via Asset → Import 3D). Returns URLs. Fetch the file with your own file tools.
| Name | Required | Description | Default |
|---|---|---|---|
| variant | No | Which variant (1-based). Default: the last one. | |
| generation_id | Yes | Generation id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns URLs (and that you must fetch files yourself), and explains the asset formats in detail. It doesn't mention error behavior, rate limits, or authentication, but for a simple retrieval tool this is acceptable. It does not claim any mutation or side effects.
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. The first sentence states the purpose and asset types; the second gives the return type and an actionable instruction. Front-loaded with the key information, and every word earns its place.
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?
The description covers the core functionality: what it returns (URLs) and how to use it (fetch with own tools). It explains asset types. However, with no output schema, it doesn't describe the structure of the returned URLs (e.g., object vs array, temporary expiry) and doesn't explicitly state the prerequisite of having a valid generation_id from a prior generation. For a simple tool this is adequate but not comprehensive.
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 coverage is 100%, so the baseline is 3. The schema descriptions are sparse: 'generation_id' just says 'Generation id' and 'variant' gives range and default. The tool description adds context by tying generation_id to a generated asset, but doesn't elaborate further. It doesn't add syntax or format details beyond the schema.
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 'Get' and the resource 'download URLs for a generated asset', and explicitly names the two formats (GLB and Roblox Studio zip) with details about their use. It distinguishes itself from siblings like generate_asset and generate_variants by focusing on retrieval rather than creation.
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?
It implies the use case: after a generation, fetch the download URLs, then use your own file tools to actually download. It gives an explicit instruction about fetching. However, it doesn't explicitly state when not to use it or contrast with siblings, though the distinction is obvious given the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Roblox-ready 3D asset from a text prompt. Returns a generation_id immediately. Poll get_generation until status is completed (usually 30–90s per variant). Styles: low-poly (default and most likely to fit the 10k target), blocky, stylized-pbr. Finished assets include measured stats and explicit compliance warnings.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | Style preset. Default low-poly. | |
| prompt | Yes | What to generate, e.g. 'a medieval treasure chest with gold coins'. | |
| variants | No | Number of variants to generate (1–4). Default 1. Each variant counts against quota. | |
| size_studs | No | Optional real-world size: the longest side of the finished model in studs (1 stud = 0.28 m), e.g. 6 for a park bench, 25 for a small house. Omit to use the model's default size. | |
| tri_budget | No | Triangle budget (500–10000). Default 10000. Models are decimated to it, then measured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so well: it discloses the async return contract, the required polling loop, and realistic latency. It also warns that finished assets carry measured stats and compliance warnings, but omits auth requirements or rate limits.
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?
Four tight sentences, purpose front-loaded, then return contract, then polling guidance, then capability notes. No sentence is filler and nothing is buried.
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?
For a five-parameter generation tool with no annotations and no output schema, the description covers the essentials an agent needs: async flow, polling target, latency, and style selection guidance. It stops short of covering quota/cost explicitly (left to the schema) and any auth or failure modes.
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 coverage is already 100%, so the baseline is 3, but the description adds real value beyond it: low-poly is flagged as the default most likely to satisfy the 10k triangle target, and the per-variant timing connects the `variants` parameter to runtime cost. Size and triangle-budget semantics remain schema-only.
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?
States a specific verb and resource ('Generate a Roblox-ready 3D asset from a text prompt') with clear domain framing, so the agent knows exactly what it produces. It does not, however, distinguish itself from the sibling generate_variants, leaving the choice between the `variants` parameter and the separate tool ambiguous.
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?
Gives concrete operational guidance: it returns a generation_id immediately and the caller must poll get_generation until status is completed, with a stated 30–90s expectation per variant. It also hints which style to pick by default and why, but says nothing about when to prefer generate_variants over this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn your own picture into a Roblox-ready 3D asset (skips text-to-image). Pass a public https URL of a PNG, JPG or WebP (≤10 MB, at least 256 px on the short side). Best input: one object, fully in frame, on a plain background. Returns a generation_id immediately; poll get_generation until status is completed. Local files are not reachable from this server: host the image somewhere public first, or upload it with POST /api/v1/generations/from-image.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional library label. Defaults to the image's file name. | |
| variants | No | Number of 3D variants of the same image (1–4, different seeds). Default 1. Each variant counts against quota; 2–4 need a paid plan. | |
| image_url | Yes | Public https URL of the image. Private, internal and IP-address hosts are refused. | |
| size_studs | No | Optional real-world size: the longest side of the finished model in studs (1 stud = 0.28 m). Omit to use the model's default size. | |
| tri_budget | No | Triangle budget (500–10000). Default 10000. Models are decimated to it, then measured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and explains the asynchronous flow: it returns a generation_id immediately and requires polling get_generation until completion. It also discloses input constraints and that local files are unreachable, though it does not cover auth, rate limits, or quota behavior in detail.
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?
The description is front-loaded with the core purpose, then moves efficiently through input requirements, best practices, async behavior, and local-file handling. Every sentence provides actionable information with no filler.
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?
For a five-parameter generation tool with no annotations or output schema, the description is largely complete: it covers accepted input, immediate return behavior, polling, and local-file alternatives. It could say more about final output or quota implications, but the schema covers the quota detail for variants.
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 coverage is 100%, so the schema already documents all five parameters thoroughly. The description adds useful input-quality guidance for image_url, such as accepted formats, size limits, and ideal image composition, but adds little for name, variants, size_studs, or tri_budget beyond what the schema provides.
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 states a specific verb and resource: turning a user's own picture into a Roblox-ready 3D asset. It explicitly distinguishes this from text-to-image generation, which lets an agent separate it from generate_asset without opening the schema.
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?
It gives clear when-to-use guidance: pass a public image URL when converting an existing picture rather than generating from text. It also names the follow-up tool get_generation for polling and gives an alternative upload endpoint for local files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate 2–4 variants of one Roblox prop prompt. Returns one generation_id immediately; poll get_generation until every requested variant is complete. Each variant runs the full pipeline and counts individually against quota.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | Style preset. Default low-poly. | |
| prompt | Yes | What to generate. | |
| variants | Yes | Number of variants (2–4). | |
| size_studs | No | Optional real-world size: the longest side of the finished model in studs (1 stud = 0.28 m), e.g. 6 for a park bench, 25 for a small house. Omit to use the model's default size. | |
| tri_budget | No | Triangle budget per variant (500–10000). Default 10000. Models are decimated to it, then measured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does so well: it discloses the async contract (returns one generation_id immediately), the required polling loop, per-variant pipeline execution, and individual quota consumption. It omits error/timeout behavior and any auth or latency expectations, keeping it short of a 5.
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?
Three sentences, each earning its place: purpose, async return plus polling instruction, and cost caveat. Front-loaded with what the tool does before the operational details.
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?
For an async tool with no output schema, the description covers the essential call contract: what is returned immediately, how to retrieve results, and the quota implication. Nothing an agent needs to invoke and then follow up correctly is missing.
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 description coverage is 100%, so parameters are already documented (size_studs example values, tri_budget decimation note, style default). The description adds only the 2–4 variant range, which is redundant with the schema's minimum/maximum. Baseline 3 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?
States a specific verb and resource with precise scope: 'Generate 2–4 variants of one Roblox prop prompt.' The variant-count scope implicitly separates it from the single-asset sibling generate_asset, though it never names that sibling explicitly the way a top-tier definition would.
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?
Gives clear follow-up workflow: poll get_generation until every variant completes, and warns each variant is billed individually against quota. It does not state when to prefer generate_asset over this tool, so the alternative-selection guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one studmill generation in full: status, error (if failed), warnings, and all variant assets with triangle counts, stud sizes and download URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| generation_id | Yes | Generation id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does so by specifying return contents: status, error, warnings, and variant assets with triangle counts, stud sizes, and download URLs. It does not discuss auth or not-found behavior, but for a simple read-style getter, the disclosed behavior is reasonably complete.
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?
The description is a single, efficient sentence that front-loads the core action and then lists the returned components in a clear, scannable format. Every phrase adds useful information with no redundancy.
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?
For a tool with one parameter, no output schema, and no annotations, the description covers the main outcome: full generation details including failure states and assets. It could mention what happens when the generation_id does not exist, but the complexity is low and the provided information is largely sufficient.
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?
The schema already describes the only parameter (generation_id) with a simple description, so schema coverage is 100%. The tool description does not add additional parameter-level guidance, which is acceptable given the high schema coverage; the baseline of 3 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?
The description uses a specific verb ('Get') and resource ('one studmill generation'), and clearly distinguishes itself from list_generations by emphasizing 'one' and 'in full'. It also enumerates the exact contents returned, making the tool's purpose unambiguous.
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 phrase 'one studmill generation in full' clearly implies this tool is for retrieving a single complete generation record, as opposed to listing generations. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your recent studmill generations (newest first) with id, prompt, style and status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the behavioral disclosure burden. It correctly implies a non-destructive read operation and adds useful traits like 'recent' (limited scope) and 'newest first' (ordering). It does not mention pagination, result limits, or auth requirements, but for a simple list operation the disclosed traits are largely sufficient.
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?
A single sentence that front-loads the verb and resource, then packs in order and field details without any redundancy. Every word earns its place.
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?
For a parameterless list tool with no output schema and no annotations, the description covers what is listed, whose data it lists, the ordering, and the returned fields. Minor omissions like whether results are paginated or capped are not critical for this simple operation.
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?
The tool has zero parameters, so the baseline is 4. The description's mention of output fields is irrelevant to parameter semantics and does not need to compensate for any schema gaps.
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 uses a specific verb ('List'), a clear resource ('your recent studmill generations'), and explicitly states ordering ('newest first') and included fields ('id, prompt, style and status'). This clearly distinguishes it from siblings like generate_asset and get_generation, which target creation or 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: an agent should use this tool to retrieve the user's own recent generation history, sorted newest first. It does not explicitly name alternatives or exclusions, but the listing semantics are unambiguous enough that an agent can infer when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a Roblox compliance receipt for every asset in one of your StudMill generations: triangle target, mobile invisibility risk (the classic 'invisible on mobile' gotcha), dimensions in studs, embedded base-color texture, and availability of the bottom-center normalized Roblox export. This validates generated assets by generation_id, not files on the caller's local disk.
| Name | Required | Description | Default |
|---|---|---|---|
| generation_id | Yes | Generation id owned by this API key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses the tool's read-only validation nature (returns a receipt, no mutation implied) and specifies the exact checks performed, plus the caveat about not touching local files. It could explicitly state there are no side effects, but the information provided is substantive and transparent.
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?
The description is two sentences, front-loaded with the core purpose and a detailed list of compliance checks, then adds the crucial scoping note about generation_id vs local files. Every clause earns its place; no filler or redundancy.
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?
For a validation tool with one parameter and no output schema, the description adequately explains what it returns (a receipt), what it validates (list of checks), and the input requirement. It doesn't specify the receipt's format or error handling, but those are not strictly necessary for an agent to call it correctly, given the tool's simplicity.
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?
The schema already provides 100% coverage for generation_id, including a description of ownership. The tool description reinforces that it validates by generation_id and not files, adding slight contextual value, but doesn't elaborate on format or additional constraints beyond the schema. Baseline 3 is appropriate since the schema handles the parameter documentation.
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 states a specific verb (return), resource (Roblox compliance receipt), and scope (every asset in a generation). It lists concrete checks (triangle target, mobile invisibility, dimensions, texture, export availability) and clarifies it operates on generation_id, not local files, distinguishing it from sibling tools like download_asset or generate_asset.
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 explicitly clarifies the input is a generation_id owned by the API key and that it validates generated assets, not local files. This provides clear context for when to use it (for compliance checks on generations) and implicitly differentiates from alternatives like get_generation or generate_variants, though it doesn't name them explicitly.
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.
generate_from_imagegenerate_asset2 fields changedInput schema / properties / size_studsAdded value: +{
+ "description": "Optional real-world size: the longest side of the finished model in studs (1 stud = 0.28 m), e.g. 6 for a park bench, 25 for a small house. Omit to use the model's default size.",
+ "maximum": 2048,
+ "minimum": 0.5,
+ "type": "number"
+}Input schema / properties / tri_budget / descriptionPrevious value: -"Triangle budget (500–10000). Default 10000."New value: +"Triangle budget (500–10000). Default 10000. Models are decimated to it, then measured."generate_variants2 fields changedInput schema / properties / size_studsAdded value: +{
+ "description": "Optional real-world size: the longest side of the finished model in studs (1 stud = 0.28 m), e.g. 6 for a park bench, 25 for a small house. Omit to use the model's default size.",
+ "maximum": 2048,
+ "minimum": 0.5,
+ "type": "number"
+}Input schema / properties / tri_budget / descriptionPrevious value: -"Triangle target per variant (500–10000). Default 10000."New value: +"Triangle budget per variant (500–10000). Default 10000. Models are decimated to it, then measured."download_assetgenerate_assetgenerate_variantsget_generationlist_generationsvalidate_roblox
Add one secure layer between your agents and this server.