Skip to main content
Glama
gchen19

AnkusDrive

by gchen19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

FEM Result Probe

fem_result_probe
Read-only

Probe FEM results at a specific point or face to retrieve stress, displacement, or temperature values there, answering 'what is the stress at this location?' for design iteration.

Instructions

Probe FEM results at a specific location, instead of only the global max + top-N that fem_results returns. Answers "what is the stress at this point / on this face?" — the agent-friendly form for design iteration.

Pick exactly one mode:

  • POINT: point=[x, y, z] (mm, model coordinates). Interpolates the field barycentrically inside the tet containing the point (method='interpolated'); if the point is outside the mesh it falls back to the nearest node and reports distance_mm (method='nearest_node').

  • FACE: handle= + face=<'f_*' tag or 'FaceN'>. Aggregates the field over the mesh nodes on that CAD face, returning {min, max, mean}.

field: 'auto' (default — every field present in the result) | 'vonmises' | 'displacement' | 'temperature'.

Pass analysis, or the job_id of a finished fem_run_submit solve.

Returns (point mode) {mode:'point', query_point, method, element_id?, node?, distance_mm, vonmises_mpa?, displacement_mm?, displacement_vector?, temperature_c?}; (face mode) {mode:'face', face, node_count, vonmises_mpa?:{min,max,mean}, displacement_mm?:{...}, temperature_c?:{...}}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
faceNo
fieldNoauto
pointNo
handleNo
job_idNo
analysisNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.5.5
    • addedInput schema / properties / analysis / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / analysis / default
      Added value: +null
    • removedInput schema / properties / analysis / type
      Removed value: -"string"
    • addedInput schema / properties / job_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Job Id"
+}
    • removedInput schema / required
      Removed value: -[
-  "analysis"
-]
  2. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations provide readOnlyHint=true but the description goes far beyond that: it discloses the interpolation method (barycentric), the fallback to nearest node with distance_mm reporting, the face aggregation behavior returning min/max/mean, and the exact result structure. This gives a complete behavioral model for a read-only probe.

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 long but every section earns its place: purpose, mode selection, mode-specific parameters, field choices, solve context, and return shapes. Bullet formatting and a clear hierarchy make it scannable, and the core purpose is front-loaded.

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?

Given the tool's moderate complexity, zero schema descriptions, and no output schema, the description provides everything needed to call it correctly: exact input formats, mode selection rules, fallback behavior, and full return shape for both modes. There are no critical gaps.

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

Parameters5/5

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

Schema coverage is 0% and the description compensates fully: point is defined as [x, y, z] in mm model coordinates, face requires handle plus a 'f_*' tag or 'FaceN', field lists allowed values including the 'auto' default, and analysis/job_id are explained as the solve context. Every parameter is meaningfully described.

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 the tool's purpose: 'Probe FEM results at a specific location,' and explicitly contrasts it with the global max + top-N returned by `fem_results`. It answers the specific design question 'what is the stress at this point / on this face?' which distinguishes it from sibling FEM tools.

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?

It tells the agent when to use this tool instead of `fem_results`, names the sibling explicitly, and explains the two mutually exclusive modes (POINT vs FACE). It also specifies how to pass the required solve context: 'Pass `analysis`, or the `job_id` of a finished fem_run_submit solve.'

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