Skip to main content
Glama

Normalize and validate many meshes in one call

batch_prepare_meshes

Batch-validate and normalize multiple .glb/.gltf meshes, repairing only those that fail checks and leaving valid ones untouched. Per-item verdicts and a summary are returned, and a single failure doesn't halt the batch.

Instructions

FREE and fully local: no network call, no credits. Runs the preparation pipeline over a list of meshes — validate, normalize the ones that fail, validate again — and returns a per-item verdict plus a summary. Meshes that already pass are left untouched rather than rewritten. One failing item never stops the run; its error is reported and the batch continues. Normalization needs a local Blender install; without one this still validates and simply reports what would need repairing. Note that a FAILED item can still have written a file: when normalization succeeds but the result does not clear the policy, the mesh is kept for inspection and named in normalizedPath with outputKept set. Use outputsWritten, not prepared, to predict how many files are in the output directory — prepared is a verdict, not a file count.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
normalizeNoRepair meshes that fail validation. When false, only reports.
outputDirNoWhere normalized copies go, resolved against the SERVER's working directory. Omit to write beside each source; an empty string is rejected rather than silently meaning "beside the source".
modelPathsYesAbsolute paths to .glb/.gltf meshes.
requireUVsNo
maxTrianglesNo
minTextureSizeNo
skipAlreadyValidNoLeave meshes that already pass untouched instead of rewriting them.
timeoutSecondsPerItemNo
Behavior5/5

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

Annotations provide no guidance (all false), so description bears full burden. It discloses every significant behavior: validation pipeline, normalization dependency on Blender, per-item error handling, that FAILED items may still write files, and the critical distinction between prepared and outputsWritten. Extremely thorough.

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

Conciseness5/5

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

A single dense paragraph with every sentence earning its place. Front-loads the free/local note and pipeline description, then addresses edge cases without redundancy. Length is justified given the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 parameters and no output schema, the description provides surprisingly complete context: batch behavior, Blender dependency, error handling, file-writing edge case, and a caution about counting outputs. No critical information for correct invocation is missing.

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 only 50%, so description must compensate. It adds meaning to outputDir (resolved against server's working dir, empty string rejected) and clarifies skipAlreadyValid behavior. However, it does not cover requireUVs, maxTriangles, minTextureSize, or timeoutSecondsPerItem, which lack schema descriptions too. Partial compensation, but not complete.

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?

States a specific verb and resource: 'Runs the preparation pipeline over a list of meshes — validate, normalize the ones that fail, validate again'. Clearly distinguishes from siblings by being a batch operation, and adds a unique free/local selling point. No ambiguity about what it does.

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?

Implies use for multiple meshes (batch) and notes free/local, but does not explicitly contrast with single-mesh alternatives like normalize_mesh or validate_game_asset. It provides clear context (list, per-item verdict) but no explicit when-not or alternative naming.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/theisegoria/game-asset-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server