studmill

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and discloses the key non-obvious behavior: the tool returns a generation_id immediately and requires polling, with typical 30–90s latency per variant. It also sets expectations by noting finished assets include measured stats and compliance warnings, though it omits quota costs and failure behavior.

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 with no wasted words: action, async polling contract, and style guidance are all front-loaded and each sentence carries distinct information. The size is proportionate to the tool's complexity.

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 generation tool with no output schema and no annotations, the description covers the call flow, polling, expected latency, style options, and result contents. It is complete enough for correct invocation; only failure modes and quota impact are left to the schema or discovered at runtime.

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 the baseline is 3. The description adds value beyond the schema by linking the low-poly default to the 10k triangle target and attaching per-variant timing, which helps an agent choose sensible parameters.

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 action ('Generate a Roblox-ready 3D asset') and the input ('from a text prompt'), making the tool's core purpose unmistakable. It does not explicitly distinguish itself from sibling generate_variants, so it stops one step short of full sibling differentiation.

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 usage context: call this to create an asset, poll get_generation until completion, and expect 30–90s per variant. It does not state when not to use it or name alternatives such as generate_variants, but the intended workflow is sufficiently clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden. It reveals three material behaviors: the call returns before generation finishes, completion must be tracked via get_generation, and each variant runs the full pipeline and consumes quota separately. This goes well beyond the schema, though it does not cover failure or auth edge cases.

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 short sentences, each earning its place: purpose, async return/polling behavior, and per-variant quota impact. The most important information is front-loaded in the first sentence, and there is 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?

The description is sufficient for an agent to invoke the tool and understand the next step (poll get_generation), despite lacking an output schema. It does not specify the shape of the immediate response beyond generation_id or what failure statuses look like, but the explicit polling instruction covers the key workflow gap.

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 description adds meaningful semantics beyond the schema by clarifying that 'prompt' is a single Roblox prop prompt and that 'variants' each trigger a full pipeline and quota charge. It does not explain style or tri_budget, but those are already well described in 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 names a specific verb ('Generate'), the resource ('Roblox prop prompt'), and the distinguishing scale ('2–4 variants'), clearly separating it from single-asset siblings like generate_asset. The first sentence alone tells an agent exactly what the tool produces.

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 clearly sets the async workflow: call this tool, get a generation_id immediately, then poll get_generation until all variants are done. It does not explicitly name generate_asset as the single-variant alternative or state when not to use this tool, so it stops short of a full when/when-not explanation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.