Skip to main content
Glama
Sign In
HydroStar MCP

HydroStar MCP

by lightninnng
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

build_geometry

Build an independently checked, provenance-preserving wetted HST geometry bundle from CAD, section, or drawing inputs for downstream HydroStar hydrodynamic analysis.

Instructions

Build an independently checked, provenance-preserving wetted HST bundle.

CAD and section data use an isolated OpenCASCADE/Gmsh process. Drawing inputs produce a metric tracing workspace. Use case_geometry from accepted output in prepare_case, with explicit mass, CG, inertia and the desired wave conditions. Choose panel_layout by topology: ring_bands for coaxial columns, station_bands for smooth x-axis lofts, polygon_blocks for a prismatic through opening, or quad_dominant for general CAD patches. Quality limits are explicit and frozen.

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": {
      "request": "<request>"
    },
    "name": "build_geometry"
  }
}

Input Schema

NameRequiredDescriptionDefault
requestYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose useful traits: CAD/section data runs in an isolated OpenCASCADE/Gmsh process, drawing inputs create a tracing workspace, results are "independently checked", and quality limits are "frozen" (i.e., not silently relaxed). It omits that this is a long-running job (the schema's timeout defaults to 600s, max 1800s), what artifacts are written and where, and what happens when quality limits cannot be met.

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-loaded with the action and artifact, then prerequisites, then the layout decision rule — a sensible order. Five dense sentences with little filler, though "independently checked, provenance-preserving" and "metric tracing workspace" are jargon that costs the reader without adding operational clarity.

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

Completeness3/5

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

For a tool with ~30 undocumented parameters, an output schema, and no annotations, the description covers sequencing and layout choice but leaves the majority of inputs uninterpretable. An agent could pick a layout and start the build, but would be guessing on units, tolerances, and volume/quality expectations.

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 0% across a large nested GeometryRequest, so the description must compensate. It does add real meaning for panel_layout, mapping four of the five enum values to topologies (triangular is unexplained), but it says nothing about units, axis_map, spline_seam, mesh_size_m, expected_volume_m3, minimum_quad_fraction, or the other undocumented fields. It also references mass, CG, inertia and wave conditions that do not appear anywhere in this schema, which may confuse an agent reading the inputs.

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?

States a specific verb and artifact ("Build ... wetted HST bundle") and signals the verification/provenance properties of the output. It also implicitly separates itself from prepare_case by naming that tool as the upstream source. The acronym-heavy phrasing ("HST bundle") keeps it from being immediately legible to an agent unfamiliar with the domain.

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?

Gives an explicit prerequisite chain ("Use case_geometry from accepted output in prepare_case") and then routes the agent on panel_layout by topology, naming four concrete layout/topology pairings. There is no when-not-to-use guidance and no mention that this is a heavy compute step to be run only after preparation is accepted for other reasons.

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