Skip to main content
Glama

run_airfoil_workflow

Generate airfoil geometry, create computational mesh, and run CFD simulation from NACA code, velocity, and angle of attack in a single call.

Instructions

Run geometry, mesh generation, and CFD as one MCP tool call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
machNoOptional Mach number override. If omitted, it is computed from velocity and speed_of_sound.
velocityYesFreestream velocity in meters per second.
naca_codeYesNACA 4- or 5-digit airfoil code, for example '0012' or '23012'.
cfl_numberNoSU2 CFL number.
domain_sizeNoFarfield domain size in chord lengths.
growth_rateNoBoundary-layer growth ratio between successive inflation layers.
mesh_formatNoMesh format. Use 'placeholder' for NeuralFoil or 'su2' for solver-effective meshes.placeholder
wake_lengthNoWake extension length downstream of the trailing edge in chord lengths.
chord_lengthNoAirfoil chord length in meters.
mesh_densityNoMesh density preset: coarse, medium, or fine.medium
low_mach_precNoEnable SU2 low-Mach preconditioning.
target_y_plusNoTarget wall y+ used to infer first_cell_height for SU2 meshes.
max_iterationsNoMaximum nonlinear iterations for the selected solver backend.
solver_backendNoSolver backend: 'neuralfoil' or 'su2'.neuralfoil
surface_pointsNoNumber of discretization points placed around the airfoil surface.
angle_of_attackYesAngle of attack in degrees.
reynolds_numberNoOptional Reynolds number override. If omitted, it is computed from velocity and chord.
turbulence_modelNoSU2 flow model: EULER, NAVIER_STOKES, or RANS.RANS
first_cell_heightNoFirst boundary-layer cell height in chord units.
n_points_per_sideNoNumber of coordinate points sampled on each airfoil side.
normalize_geometryNoNormalize the generated airfoil to unit chord before scaling.
su2_timeout_secondsNoMaximum wall-clock time allowed for the SU2 subprocess.
convergence_residualNoSU2 convergence target expressed as log10 residual.
gmsh_timeout_secondsNoMaximum wall-clock time allowed for the Gmsh subprocess.
boundary_layer_layersNoNumber of boundary-layer inflation layers for SU2/Gmsh meshes.
reference_reynolds_numberNoReference Reynolds number used with target_y_plus to infer first_cell_height.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits, but it only lists the three steps without mentioning runtime expectations, resource consumption, side effects like intermediate file writes, or any caveats about the workflow. For a complex multi-stage tool, this is a significant transparency gap.

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?

The description is a single, direct sentence that efficiently communicates the core purpose without any redundant or irrelevant information. It is appropriately front-loaded and concise.

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

Completeness2/5

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

Despite having a full input schema and an output schema, the description is far too sparse for a tool orchestrating three complex simulation stages. It omits any information about what the workflow returns, expected execution time, or how it differs from chaining the sibling tools manually, leaving substantial gaps for an AI agent.

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?

The schema fully documents all 26 parameters with descriptions, so the baseline is 3. The description adds no extra semantic context about how parameters relate to the workflow or any non-obvious interactions, but the schema carries the load.

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 clearly states that the tool runs a composite workflow of geometry generation, mesh generation, and CFD simulation in one MCP call. It distinguishes itself from sibling tools like generate_airfoil_geometry and run_cfd_solver by being the aggregate workflow.

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool versus invoking the sibling tools separately. It does not mention scenarios where a full workflow is preferred or when individual steps should be used instead, leaving usage entirely implied by the name.

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/DaveFan-NCHC/MCP-Server-for-CFD'

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