Skip to main content
Glama
Sign In
paprika3d

paprika3d

Official
by Keeno-Corp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

model_audit

Inspect .glb, .gltf, and USD 3D models for file size, triangle count, textures, and compression; get a site or Shopify budget verdict, then shrink oversized GLB/GLTF files.

Instructions

Inspects 3D model files (.glb, .gltf, and USD: .usd, .usda, .usdc, .usdz): megabytes, triangles, materials, each texture's size and format, and whether it uses Draco, meshopt and KTX2, for one file or every one under a folder (path, relative to cwd; the whole project when left out), read from the file itself with no decoder, so Draco and meshopt files report too. Then a one-line verdict on what a website or a Shopify listing judges a model on, against target: site (the site budget: 4 MB of assets, 200,000 triangles, 2048 px textures by area) or shopify (a GLB of about 4 MB with textures at most 2048 px on a side). shrink rewrites one .glb or .gltf smaller, without its textures or with each capped at a size (WebP), and replies with before and after (a USD file is converted to GLB first); a failing file gets the shrink call that fixes it: save a look first (look save), shrink, point the page at the new file, then look compare.

Input Schema

NameRequiredDescriptionDefault
cwdYesThe game project's folder.
pathNoA .glb, .gltf or USD file, or a folder to report every one under, relative to cwd.
shrinkNoRewrite the file smaller: textures false drops them all (geometry only), a number caps each texture's longer side at that many pixels (WebP); out is the new file (<name>-opt.glb by default). Replies with before and after.
targetNoWhat to judge the files against (site by default).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description does the heavy lifting: it discloses that metrics are read from the file itself with no decoder (so Draco/meshopt files still report), that USD is converted to GLB before shrinking, that `out` defaults to <name>-opt.glb, and that shrink replies with before/after. It never explicitly confirms the original file is left untouched on shrink, which is the one behavioral gap an agent would care about.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is one dense, run-on paragraph that folds three distinct capabilities plus a workflow into a single wall of text. Information is front-loaded (audit first, shrink last), but the packing into long clauses hurts scanability even though little is truly redundant.

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-param tool with a nested `shrink` object and no output schema, the description covers the return content reasonably (metrics list, one-line verdict, before/after on shrink) and the non-obvious preconditions (no decoder needed, USD→GLB conversion). Some output detail (e.g. exact verdict format or what counts as failing) is still implicit.

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 3 is the floor. The description earns above that by adding meaning the schema lacks: the concrete budget numbers behind `target` (4 MB / 200k triangles / 2048 px for site; ~4 MB GLB, 2048 px per side for Shopify) and the semantics of `shrink.textures` (false drops all, a number caps the longer side as WebP).

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 and resource ('Inspects 3D model files') and enumerates exactly what it reports (megabytes, triangles, materials, per-texture size/format, Draco/meshopt/KTX2), plus the verdict and shrink capabilities. An agent can tell what this tool does without opening the schema, and it names the concrete ecosystems (website/Shopify) it judges against.

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?

It gives clear usage context: audit one file or a whole folder, judge against 'site' or 'shopify', and it walks the remediation flow ('save a look first (look save), shrink, point the page at the new file, then look compare'). What's missing is an explicit boundary against siblings like model_run or optimize — it never says when *not* to reach for this tool.

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

Deploy Server

Other Tools