NovaSolver Studio MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

run_genesis

Runs Genesis topology optimization on a case's meshed part using its boundary conditions and manufacturing constraints, then returns a closed STL or a job ID for status checks.

Instructions

Genesis topology optimisation of the case's part: the meshed part is the design space, its face conditions (fixed / symmetry / constraint / load / pressure / moment / bearing / remote-force, or temperature / heat-flux for heat cases) are the supports and loads. Minimises compliance (stiffest part, or lowest heat-weighted temperature) for the volume_fraction of material kept. Manufacturing options: symmetry planes (through the part's centre), extrusion direction (milling/casting: the shape is constant along that axis), overhang = build direction for 3D printing (no overhang beyond 45 degrees). min_member_mm sets the filter and the thinnest member aimed for; the result reports the measured one. Faces with conditions stay solid (keep_bc_faces) and keep_faces adds more. Symmetry planes that the supports and loads share are solved on the half model (same design, about half the time). refine=True adds a finishing pass: the part is re-optimised near its surface on a grid about twice as fine (same minimum member in mm), kept only when it is stiffer; about 2-3x the time, not with cells above ~400k. Returns a job_id when it does not finish in ~20 s: call job_status. The result is a closed STL (with extrusion also a flat-faced STEP); analyse it again (stress, CalculiX) before use.

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": {
      "case_id": "<case_id>"
    },
    "name": "run_genesis"
  }
}

Input Schema

Name	Required	Default
`cells`	No
`refine`	No
`case_id`	Yes
`language`	No	ja
`overhang`	No
`symmetry`	No
`extrusion`	No
`iterations`	No
`keep_faces`	No
`skin_cells`	No
`keep_bc_faces`	No
`min_member_mm`	No
`volume_fraction`	No
`heat_source_w_m3`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.8.0Nov 13, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (which only say it is not read-only and not idempotent), the description discloses asynchronous behaviour (~20 s threshold returning a job_id), the cost profile of refine (~2-3x time, prohibited above ~400k cells), the half-model symmetry shortcut, and the exact output artifacts (closed STL, flat-faced STEP with extrusion). These are precisely the operational facts an agent needs before committing to a long run.

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?

Purpose is front-loaded and every clause is information-dense, though it reads as one long block rather than a structured list, which makes the dense physics terminology harder to scan. There is no filler, but sentence length could be reduced for readability.

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?

For a 14-parameter, no-output-schema compute tool, the description covers the objective, key inputs, runtime caveats, async fallback and return artifacts well. Gaps remain around undocumented parameters (iterations, skin_cells, language) and any expected failure modes, but nothing critical to invoking 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 description coverage is 0%, so the description must carry the burden, and it does for the important parameters: volume_fraction, min_member_mm (sets the filter and target member thickness, with the measured value reported), symmetry, extrusion, overhang (build direction with the 45-degree rule), keep_bc_faces, keep_faces and refine. It leaves iterations, skin_cells, language and heat_source_w_m3 unexplained, so a few parameters remain opaque.

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 and resource: 'Genesis topology optimisation of the case's part', and immediately clarifies that the meshed part is the design space with face conditions as supports/loads. It states the objective (minimise compliance for the given volume_fraction, or lowest heat-weighted temperature for heat cases), which cleanly separates it from simulation siblings like run_simulation or instant_estimate.

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

Usage Guidelines4/5

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

It gives concrete routing guidance: call job_status when a job_id is returned instead of finishing in ~20 s, and analyse the closed STL/STEP again (stress, CalculiX) before real use. It also states a precondition for refine (not with cells above ~400k). What it lacks is an explicit 'use this instead of X when...' comparison against alternatives such as run_simulation for a quick analysis.

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