Skip to main content
Glama

Validate scene

scene_validate

Validate a revision against a profile; returns issues with codes, severities, and suggested candidate operations. Default: synchronous, from the stored scene summary. deep=true opens the scene in Blender for real mesh analysis (non-manifold, watertight, degenerate, overhangs) and returns a job handle (idempotencyKey required). General deep validation checks evaluated watertightness (open surfaces warn) and zero-area faces/zero-length edges (errors). additionalChecks can add interior_faces and uv_layers. The queued response states requested coverage; completed reports state actual object counts and skipped/partial checks, including pair-budget limits. intersectionMaxPairTriangleWork can raise cumulative pair work from 8 million to at most 64 million; time and memory caps stay fixed. Validation can be scoped with objectNamePattern/excludeNamePattern. intersectionMaxDepthSamples separately raises optional penetration sampling from 32,000 to at most 256,000 within the same time cap. Sampling completion is separate from candidate-pair coverage. resumeFrom with deep=true continues remaining depth samples on the source's exact revision/settings without repeating collision detection. Only the per-job depth sample budget may change; historical reports without checkpoints cannot resume. Repair suggestions can be alternatives: read suggestedOperationsMode and suggestedOperationsNote before applying them. job_get/job_wait return checked totals plus reportArtifactId. Use job_report with this jobId for complete summary totals and ordered issue/object/print-object pages or section=report for all JSON bytes. Inline details may be truncated; profile three_d_print carries a print report (dimensions mm, volume, filament estimate, bed fit). If a deep run does not give you what you need, mesh.analyze_quality is the SECOND route to the same class of measurement: it reports non_manifold, zero_area_faces, degenerate_edges, sharp_angles, stretched_uvs and interior_faces, and it runs INSIDE a scene_apply batch, so you can measure and repair in one job. A build whose deep validation returned nothing downloaded the GLB and wrote its own topology checker instead, because nothing said this existed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deepNo
profileNoDefault general; continuation inherits its source profile.
projectIdYesStable project ID returned by project_create or projects_list.
resumeFromNoCompleted source validation and immutable report; requires deep=true and a partial resumable depth checkpoint.
revisionIdNo"HEAD" (default) uses the project's current head
idempotencyKeyNoStable caller-chosen key for safe retries of this same request.
additionalChecksNoDeep-only checks added to the profile: interior_faces tests faces whose every edge has more than two face users; uv_layers checks UV presence. Interior-face topology is not an exhaustive volumetric self-intersection test.
objectNamePatternNoRestrict validation to objects whose name matches, e.g. "Watch_*". Without this a studio backdrop is included in the print bounding box, reporting a 42 mm product as 1870 mm and making the three_d_print report unusable.
excludeNamePatternNoDrop objects whose name matches, e.g. "Studio_*". Applied after objectNamePattern. Use this when the parts you care about share no common prefix — which is the normal case for an assembly (Case_Body, Bezel_Ring, Dial_Plate, Crown…). Include-only filtering left no way to say "everything except the backdrop", so the backdrop's own open shell and its bounding box polluted every report and a field build hand-triaged 51 findings down to the 3 that were real.
intersectionMaxDepthSamplesNoDeep-only optional penetration-depth sample budget, shared across detected pairs. Default 32,000; maximum 256,000. Sampling runs after surface-crossing detection and does not change candidate-pair coverage. The existing 20-second deadline and geometry caps still apply. Inspect depthSamplesComplete and each penetrationDepthStatus; a larger budget does not guarantee a depth witness or an exhaustive maximum. Scope objects with objectNamePattern/excludeNamePattern. When pair detection completed and the report contains a partial depth checkpoint, scene_validate.resumeFrom continues its remaining samples on the pinned revision. Otherwise a new scoped validation repeats the work.
intersectionMaxPairTriangleWorkNoDeep-only cumulative intersection pair work: the sum of both objects' evaluated triangle counts for each checked pair. Default 8,000,000; maximum 64,000,000. A larger budget can complete more pairs using cached trees. The 20-second deadline, tree geometry and candidate storage limits remain fixed; optional depth samples have a separate intersectionMaxDepthSamples budget. The job's execution deadline still applies. Retry with a new idempotencyKey; this reruns the check rather than resuming it. Read actual coverage; raising this limit never guarantees a pass.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / intersectionMaxDepthSamples / description
      Previous value: -"Deep-only optional penetration-depth sample budget, shared across detected pairs. Default 32,000; maximum 256,000. Sampling runs after surface-crossing detection and does not change candidate-pair coverage. The existing 20-second deadline and geometry caps still apply. Inspect depthSamplesComplete and each penetrationDepthStatus; a larger budget does not guarantee a depth witness or an exhaustive maximum. Scope objects with objectNamePattern/excludeNamePattern and retry with a new idempotencyKey when needed."New value: +"Deep-only optional penetration-depth sample budget, shared across detected pairs. Default 32,000; maximum 256,000. Sampling runs after surface-crossing detection and does not change candidate-pair coverage. The existing 20-second deadline and geometry caps still apply. Inspect depthSamplesComplete and each penetrationDepthStatus; a larger budget does not guarantee a depth witness or an exhaustive maximum. Scope objects with objectNamePattern/excludeNamePattern. When pair detection completed and the report contains a partial depth checkpoint, scene_validate.resumeFrom continues its remaining samples on the pinned revision. Otherwise a new scoped validation repeats the work."
    • removedInput schema / properties / profile / default
      Removed value: -"general"
    • addedInput schema / properties / profile / description
      Added value: +"Default general; continuation inherits its source profile."
    • addedInput schema / properties / resumeFrom
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Completed source validation and immutable report; requires deep=true and a partial resumable depth checkpoint.",
      +  "properties": {
      +    "artifactId": {
      +      "description": "Artifact ID returned by a completed job or artifacts_list.",
      +      "type": "string"
      +    },
      +    "jobId": {
      +      "description": "Durable job ID returned when an asynchronous operation is queued.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "jobId",
      +    "artifactId"
      +  ],
      +  "type": "object"
      +}
    • removedInput schema / properties / revisionId / default
      Removed value: -"HEAD"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations are all default false, so the description carries the full burden of behavioral disclosure — and it delivers: sync-vs-async semantics, Blender opening for deep mode, idempotencyKey required for deep, queued vs completed report content, pair-budget and time caps, sampling completion separate from candidate-pair coverage, resume limitations ('historical reports without checkpoints cannot resume'), possible inline truncation, and the warning that repair suggestions can be alternatives. No contradiction with the annotations.

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 long (~450 words) but nearly every sentence carries unique information for an 11-parameter tool with no annotations and no output schema. Purpose is front-loaded, and unlike under-specification, this is dense specification. It loses a point for being a wall of text with structural redundancy (budget figures repeated from the schema) rather than organized sections.

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 no output schema and no meaningful annotations, this description must cover sync/async return shapes, how to retrieve complete results (job_get/job_wait, job_report with section=report), truncation caveats, budget limits, resume rules, repair-suggestion caveats, and the alternative route. It covers all of these, plus a 'what not to do' war story showing the failure mode it is designed to prevent. Nothing an agent needs to call it correctly 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 91%, so the baseline is 3, but the description adds value beyond the schema for several parameters: deep=true's meaning (opens Blender, returns job handle), the practical failure modes for objectNamePattern/excludeNamePattern, the semantics of resumeFrom (continues remaining depth samples without repeating collision detection), and profile-specific output for three_d_print. Some restatement of numeric budgets duplicates the schema, but the added interpretive context justifies a 4.

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 statement: 'Validate a revision against a profile; returns issues with codes, severities, and suggested candidate operations.' This names the resource (revision), the verb (validate), and the concrete output shape, and it is immediately distinguishable from siblings like scene_apply, scene_inspect, and mesh.analyze_quality, which the description explicitly contrasts with the primary route.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when/when-not guidance: default synchronous shallow path vs deep=true for Blender mesh analysis, when resumeFrom applies versus when a new scoped validation must be repeated, and when objectNamePattern/excludeNamePattern is needed (with concrete failure stories: a 42mm product reported as 1870mm; 51 findings hand-triaged to 3). It names an explicit alternative — 'mesh.analyze_quality is the SECOND route to the same class of measurement' — and tells the agent to read suggestedOperationsMode/suggestedOperationsNote before applying repairs.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources