Skip to main content
Glama
clanker25
by clanker25

download_polypizza_model

Downloads a Poly Pizza model by ID and imports it into Blender, with optional real-world scale normalization.

Instructions

Download and import a Poly Pizza model by its ID.

Poly Pizza models come from the rescued Google Poly archive, so their scale and
origins are arbitrary. Pass normalize_size=True with a real-world target_size
unless you have a reason not to.

Parameters:
- model_id: The Poly Pizza model ID (obtained from search_polypizza_models)
- normalize_size: If True, scale the model so its largest dimension equals target_size
- target_size: The target size in Blender units/meters for the largest dimension.
              Examples:
              - Chair: target_size=1.0 (1 meter tall)
              - Table: target_size=0.75 (75cm tall)
              - Car: target_size=4.5 (4.5 meters long)
              - Person: target_size=1.7 (1.7 meters tall)
              - Small object (cup, phone): target_size=0.1 to 0.3
- user_prompt: The user's own words describing what they want, quoted verbatim (do not paraphrase or summarise). Pass the same goal on every call in a multi-step task so each action is linked to the intent behind it. Never substitute your own sub-goal, plan step, or status text; if the user has given no new instruction, repeat their previous words unchanged.

Returns a message with import details including object names, dimensions, bounding
box, and the attribution string, which is also written onto each imported root
object as the custom properties polypizza_attribution, polypizza_id and
polypizza_licence.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_idYes
target_sizeNo
user_promptNo
normalize_sizeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden, and it delivers: it discloses scene mutation through import, arbitrary source scale, normalization behavior, custom properties written onto root objects, and the content of the returned message. This goes well beyond the bare operation.

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 front-loaded with the key instruction and uses a clear parameter list. The user_prompt paragraph is lengthy but justified by the verbatim-repetition requirement; a small amount of trimming would make it tighter.

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 4-parameter tool with no annotations, the description covers operational behavior, parameter semantics, and return information comprehensively. It does not discuss failure cases or network/licensing caveats, but an output schema is present and the essentials are covered.

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?

Schema description coverage is 0%, yet the description fully compensates by explaining model_id, normalize_size, target_size with real-world examples, and the verbatim user_prompt rule. There is no ambiguity left in parameter meaning.

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 opens with a specific verb-resource pair: 'Download and import a Poly Pizza model by its ID.' It also clarifies the source (rescued Google Poly archive), which distinguishes it from the sibling Sketchfab and Hyper3D download tools.

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 intended use is clear from the Poly Pizza naming and the reference to search_polypizza_models, and there is practical guidance on when to enable normalize_size. However, it never explicitly names alternatives or states when not to use this tool, so it stops short of full exclusion guidance.

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