mesh-ops

Cross-adapter polygon modeling recipes for the shared cross-DCC modeling vocabulary. Every recipe is a DCC-agnostic plan: a validated inputs_schema, an ordered list of steps that dispatch the canonical mesh_ops__<verb> tool, a Draft 2020-12 output_contract, and a toolset_profiles: [mesh-ops] binding.

How to use

1. recipes__list with skill: mesh-ops to see the available recipes.
2. recipes__get a recipe to read its inputs_schema, steps, and output_contract.
3. recipes__validate candidate inputs against the recipe schema before dispatching.
4. recipes__apply to obtain the execution plan, then materialize and dispatch the returned steps (see "Dispatch contract" below).

Cross-adapter contract

• dcc: any — a recipe is not tied to one host; the same plan applies in every DCC adapter that implements the shared modeling verb.
• toolset_profiles: [mesh-ops] — the recipe belongs to the mesh-ops toolset carried by each adapter's mesh-ops skill.
• steps[].tool uses the canonical mesh_ops__<verb> name, never an adapter-specific slug.
• inputs_schema is a Draft 2020-12 schema validated by Core without a runtime jsonschema dependency.

Dispatch contract

recipes__apply returns the plan verbatim. Core does three things only: validate inputs against inputs_schema, attach the output_contract, and return the steps. It does not substitute ${param} placeholders and does not apply inputs_schema defaults. The caller must materialize each step:

step.arguments[k] == "${name}"  ->  inputs[name] if present
                                    else inputs_schema.properties[name].default

Every placeholder therefore names an input property that is either listed in required or carries a default, so a materialized step never still contains a ${...} string. The test suite asserts this for every recipe.

Resolve mesh_ops__<verb> through tool_routing in RECIPES.yaml:

• tool_routing.tools[<verb>][<adapter>] — the concrete tool that adapter publishes (blender_mesh_ops__bevel_edges, maya_mesh_ops__mirror_mesh, houdini_materials__assign_material, …).
• null — the adapter publishes no equivalent. Use tool_routing.scripting_fallback[<adapter>] and project the script result onto the output_contract yourself.

tool_routing resolves the tool, not the argument shape. Step arguments use the canonical vocabulary above; projecting them onto an adapter's own signature is that adapter's job — Maya's combine_meshes takes objects and name where the canonical recipe says object_names and new_name, and Maya's loft_sections takes name where the recipe says output_name. When an adapter cannot express a canonical argument, use the scripting fallback rather than dropping it.

Output contract

output_contract is a Draft 2020-12 schema, not a label. After the tool runs, project the observed result onto the declared receipt and validate it. The contracts are deliberately fail-able:

• every mutating recipe requires changed: true, so a tool that reports success without touching the mesh cannot pass;
• get_poly_count requires changed: false, so a mutating implementation cannot pass a read-only recipe;
• component edits require the affected component list plus a post-operation element count;
• auto_uv requires uv_count >= 1 and a SHA-256 uv_digest, so a mesh that ends up without UVs fails the contract — the failure mode that shipped an FBX with 31% of meshes un-UV'd.

Validate with jsonschema.Draft202012Validator, or with Core's dependency-free validator (dcc_mcp_core._runtime.recipe_schema._RecipeSchemaValidator) on Python 3.7 hosts.

Adapter-local duplicates

Some adapters ship their own recipe pack (for example Maya's maya-mesh-ops). adapter_recipe_aliases in RECIPES.yaml maps each cross-adapter verb to the adapter-local recipe name. When a recipes__search query matches both, prefer the adapter-local entry (dcc: <adapter>) — its steps and contract are verified against that host's real tools — and fall back to the cross-adapter entry (dcc: any) when the adapter publishes no local recipe.

Read RECIPES.yaml for the full recipe list.