Skip to main content
Glama

FEM Run Submit

fem_run_submit
Destructive

Run a CalculiX simulation asynchronously to avoid blocking the channel: write input, start solver in background, then poll job_status until 'done' and retrieve results with fem_results.

Instructions

Run the CalculiX solver on an analysis OFF the MCP channel — the submit→poll form of fem_run, for solves long enough to stall the channel (see fem_run for which to use).

The solver input is written before this returns, so a missing solver, material or mesh fails here, synchronously, exactly as fem_run would. ccx then runs in the background. Poll job_status: once ccx exits, the results are imported into the analysis on your NEXT poll (FreeCAD work runs on the worker's main thread, which a poll gives a turn) — so keep polling until status is 'done'; a job nobody polls never finishes. A ccx error fails the job with its *ERROR lines.

When done, read results with fem_results / fem_result_probe / fem_modal_results / fem_buckling_results / fem_thermal_results passing either analysis or this job_id (don't job_result(discard=True) first if you plan to use the job_id). While the job runs, fem_run or another submit on the same analysis or workdir is refused. Returns {job_id, status, cache_hit}; job_result's result is fem_run's return dict.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workdirNo
analysisYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.5

TDQS

A4.5/5.0
Behavior5/5

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

The description goes far beyond the sparse annotations, explaining synchronous validation failure, background execution, results imported on the next poll, no polling means the job never finishes, ccx *ERROR lines fail the job, and concurrency restrictions. There is no contradiction with the annotations.

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?

The text is relatively long but well organized, moving from purpose to execution model to lifecycle/result handling. The length is justified for a complex async tool, and no sentence is filler; however, a couple of phrases (e.g. the repeated `analysis` or `workdir` references) could be tightened, keeping it just short of a 5.

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?

Despite having no output schema and minimal param schema, the description covers the full call lifecycle, validation timing, polling protocol, results, concurrency, return dict, and how to read into results tools. Minor gaps remain around the exact meaning of `analysis`, `workdir`, and `cache_hit`, but overall the agent knows what to do.

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 0% schema description coverage, the description carries the full burden, but it only adds context around `analysis` and `workdir` indirectly through the workflow text. It doesn't explicitly define what value should be passed as `analysis`, how `workdir` is used, or the relation between them, so it only partially compensates.

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, resource, and mode: 'Run the CalculiX solver on an analysis OFF the MCP channel — the submit→poll form of fem_run, for solves long enough to stall the channel'. It names fem_run and clearly differentiates the async variant, so an agent can distinguish this tool without opening other schemas.

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 gives a concrete usage criterion ('solves long enough to stall the channel'), likely sets the threshold for when to pick this over fem_run, and points to fem_run for the alternative. It also includes an explicit exclusion: while a job runs, 'fem_run or another submit on the same analysis or workdir is refused'. This is clear when/when-not guidance.

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