Skip to main content
Glama
Meteor-Simulation

BULC MCP

Official

Auto multimesh

auto_multimesh
Destructive

Build a multi-mesh deck from obstruction geometry, measuring fluid gaps and sizing cells; refuses overlapping, gapped, or misaligned meshes.

Instructions

Build a multi-mesh deck from the OBSTRUCTION geometry. It measures the fluid gap everywhere (obstacles minus HOLEs, so doorways stay open), gives narrow places 3+ cells across and open places the default wide cell, then merges equal-size regions into boxes cut on obstacle faces so walls stay on mesh boundaries. Wall slabs up to 2 cells thick are absorbed into a neighbour. Cell sizes are quantised to min_cell x 2^k; an overlapping, gapped or misaligned deck is refused, not committed. The domain may grow to a multiple of the coarsest cell; OPEN vents follow. Engine constraints (engine multimesh ratio_union_grid): (1) every mesh must use CUBIC cells whose size is the finest cell x 2^k (k in 1,2,4,8,16); (2) every mesh boundary and the union extent must land on a fine-grid index that is a multiple of the LARGEST ratio actually used; (3) meshes must tile the domain with no overlap and no gap; (4) a 1:4 or larger ratio makes the engine print an experimental-feature warning and switches it to per-mesh storage (MM2) plus the composite block-CG v2 pressure solve, both automatically. Verify the result with list_meshes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_cellYesCoarsest cell size (m), e.g. 0.2. Rounded DOWN to min_cell x 2^k.
min_cellYesFinest cell size (m), e.g. 0.05. Must be > 0; it is the bottom of the 2^k ladder.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.0.0

TDQS

A4/5.0
Behavior5/5

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

Annotations already flag destructive/non-idempotent, but the description adds substantial behavior beyond them: an invalid deck is 'refused, not committed', the domain may grow to a multiple of the coarsest cell with OPEN vents following, and a 1:4+ ratio silently switches the engine to MM2 storage plus composite block-CG v2. That is exactly the side-effect detail an agent needs.

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 what-is-built sentence is front-loaded before the constraints, so the important part lands first. It is dense and long with parentheticals, and the min_cell x 2^k quantisation is stated twice, but the length is largely justified by the complexity of the operation.

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?

For a destructive, non-idempotent mesh generator with no output schema, the description covers inputs' effect, refusal behavior, domain growth, engine side effects, and a verification step. An agent has everything needed to call it and interpret the outcome.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents the 'rounded DOWN to min_cell x 2^k' rule that the description restates. The extra engine-constraint ladder (k in 1,2,4,8,16) gives marginal added meaning, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb+resource ('Build a multi-mesh deck from the OBSTRUCTION geometry') and the algorithm detail makes the tool unmistakable. It never explicitly contrasts itself with the closely related siblings (auto_cutcell_mesh, auto_fit_mesh, set_meshes), so the sibling-differentiation half of the top criterion is only implied.

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

Usage Guidelines3/5

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

Usage is implied by the description ('Build a multi-mesh deck...') and one follow-up alternative is named ('Verify the result with list_meshes'). However, there is no guidance on when to prefer this over auto_cutcell_mesh, auto_fit_mesh, or set_meshes, and no stated prerequisites or exclusions.

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