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 6 tools
Each tool has a clearly distinct role in the generation pipeline: create single, create multiple, poll status, list history, download results, and validate. No overlapping purposes or likely confusions.
All tool names follow a consistent snake_case verb_noun pattern (generate_asset, get_generation, list_generations, validate_roblox). Naming style is uniform and predictable.
Six tools is well-scoped for the domain of generating and verifying Roblox 3D assets. Each tool covers a necessary step without redundancy or bloat.
The core lifecycle is covered: create, poll, list, download, and validate. Minor gaps exist such as no cancel or delete operations, but the main workflow has no dead ends.
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. |
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. |
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_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.