Skip to main content
Glama

Gradient Dynamics: thermal and CFD simulation

Check mesh request

validate_mesh
Read-onlyIdempotent

Validate structured, octree/prism or OpenFOAM meshing configuration without compute. All engines default to ±30% cell-count tolerance; leave cell_count_tolerance omitted unless the user requests another tolerance. A target count alone does not imply ±5%. Domain coordinates have engine-specific units; returns clarification/default guidance and configured routing. This checks the contract, not native geometry; use inspect_mesh_geometry for structured component IDs, and check_geometry and plan_mesh for what the octree mesher will make of it. Quality is assessed after execution.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "surface_artifact_id": "<surface_artifact_id>",
      "engine": "<engine>"
    },
    "name": "validate_mesh"
  }
}

Input Schema

NameRequiredDescriptionDefault
engineYesstructured = Cartesian; octree_prism = native octree/polyhedral with prism layers; openfoam = legacy engine identifier. Prefer configured octree_prism for generic unstructured requests; preserve explicit methods. Choose delivered file formats separately with export_formats.
openfoamNo
project_idNo
structuredNo
octree_prismNo
target_cellsNo
export_formatsNoDelivered mesh formats, in preference order. Default cgns is Standard CGNS (NGON/NFACE) for ParaView. gd_cgns is GD CGNS for Fluxcore/Studio; fluent is a Fluent-format polyhedral .msh; openfoam is a polyMesh archive. Select formats independently of the meshing engine. The first format is the primary download. GD CGNS is also retained internally for simulation and viewing. Preserve an explicit user choice; do not ask for a format when none was specified.
reviewed_job_idNoExplicitly requested new attempt after reviewing this completed mesh job, including quality or resource failures. Use a fresh idempotency key; this records lineage and never restarts the prior execution.
decision_contextNo
surface_artifact_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and no destruction, so the description is free to add genuine context: it does no compute, validates the contract rather than native geometry, and returns clarification/default guidance plus configured routing. The disclosed ±30% tolerance default and the note that 'a target count alone does not imply ±5%' are real behavioral disclosures an agent could not infer from annotations or schema.

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?

Front-loads the purpose and scope, then the tolerance default, then routing to siblings. It is dense but every sentence carries information; the 'A target count alone does not imply ±5%' line is slightly defensive but guards against a plausible misread.

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?

An output schema exists, so return values need no prose. For a read-only 10-parameter validator with deeply nested option objects, the description covers purpose, defaults, when-not-to-use, and where to get more schema detail, which is nearly enough; a little more guidance on engine choice versus export formats would close the gap.

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?

With 10 parameters and only 30% schema description coverage, the description compensates partially: it explains cell_count_tolerance defaults and warns that domain coordinates carry engine-specific units. It says nothing about engine selection trade-offs beyond a passing reference, or about export_formats, reviewed_job_id lineage, or retry policies, leaving most parameters to the nested schema and the get_tool_schema pointer.

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?

Opens with a specific verb and resource: validate a structured, octree/prism or OpenFOAM meshing configuration, with the key scope qualifier 'without compute'. It is immediately distinguishable from siblings like create_mesh and plan_mesh, since it only checks the request contract.

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?

Explicitly routes the agent to alternatives by condition: inspect_mesh_geometry for structured component IDs, check_geometry and plan_mesh for what the mesher will make of the geometry, and quality assessment after execution. It also tells the agent to leave cell_count_tolerance omitted unless the user asks otherwise, which is a strong default-behavior rule.

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