DIANA-MCP

diana_run_solver

Solve approved DIANA baseline or campaign variant models from .dat/.dcf files after permit and parameter-envelope checks, writing results beside the .dat.

Instructions

Solve an already trusted baseline or approved parameter variant from .dat/.dcf files.

This is the fast solver stage, not a way to build or bypass review. Exactly one baseline_id or campaign_id is required. A baseline pair must be byte-for-byte identical to the archived model that passed GUI review, validation solve and post-solve checks. A campaign variant must provide the complete approved parameter values and a semantic change manifest; both are range/envelope checked and all files are bound to a one-use permit before the common process-launch layer can run diana.exe.

Outputs .out/.tb/.dnb are written next to the .dat. A .dcf exported by DianaIE (analysis blocks only) is completed with the *FILOS/INITIA/*INPUT header (after any ':' comments and control commands) and *END that a standalone run needs; that and the TABULA layout options go into a copy, .run.dcf. The original file is not modified. Relative input files it refers to (user DLLs via *FORTRAN USE, *INPUT READ FILE=, IMPORT) must be next to the .dcf or .dat; missing ones are reported before the run.

Args: dat_path: absolute path of the model file (.dat). dcf_path: absolute path of the command file (.dcf). name: base name of the outputs (default: the .dat file name). threads: threads for element loops (diana.exe -n); solver threads are set by SOLVE PARDIS MAXTHR in the .dcf. overwrite: delete outputs of an earlier run with the same name first (DIANA appends to an existing .dnb). keep_ff: keep the FILOS database (.ff) after the run. tb_no_paging: write TABULA (.tb) output without page layout (LINPAG 0, COLLIN 1000). tb_digits: significant digits of results in the .tb (1-10; DIANA's default is 4). restart_ff: continue on this existing FILOS database (.ff) instead of initializing one: restarts, RESTOR, or a stand-alone *REDUCT / *ELIQUE / *ECREEP after the analysis that created it (manual H.2, H.16.4, H.17-H.19). The .dcf is then used as written (start it with *FILOS / UNLOCK after a killed run) and the database is kept. baseline_id: certified baseline whose exact files are being solved. campaign_id: GUI-approved parameter-study plan for a variant. case_parameters: complete name/value map required by the campaign. change_manifest: model/solver paths changed from the baseline, using the paths displayed in the campaign.

Input Schema

Name	Required	Description	Default
`name`	No
`keep_ff`	No
`threads`	No
`dat_path`	Yes
`dcf_path`	Yes
`overwrite`	No
`tb_digits`	No
`restart_ff`	No
`baseline_id`	No
`campaign_id`	No
`tb_no_paging`	No
`case_parameters`	No
`change_manifest`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.10.0Nov 4, 2026

TDQS

A4.5/5.0

Behavior5/5

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

No annotations are supplied, so the description carries the full burden and does so thoroughly: permit binding, range/envelope checks, the fact that the original .dcf is not modified while a derived <name>.run.dcf is written, that outputs land next to the .dat, that missing relative input files are reported before the run, and that DIANA appends to an existing .dnb unless overwrite is set.

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 purpose and the exactly-one-of constraint before the behavioral detail, then a well-organized Args block. It is long, and a few clauses (e.g. the manual section references H.2/H.16.4) are dense, but nearly every sentence carries operational information rather than restating the name.

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?

An output schema exists, so return values need not be described. For a process-launching, file-mutating tool with no annotations, the description still covers trust gates, file placement, overwrite hazards, restart semantics, and pre-run validation of relative inputs — everything an agent needs to avoid a bad call.

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 description coverage is 0% across 13 parameters, so the description must compensate entirely, and the Args block does: threads maps to diana.exe -n while solver threads come from SOLVE PARDIS MAXTHR, tb_no_paging sets LINPAG 0/COLLIN 1000, tb_digits is bounded 1-10 with DIANA's default of 4, and restart_ff explains what the .dcf must then contain.

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?

The description opens with a specific verb and resource: solve an already-trusted baseline or approved campaign variant from .dat/.dcf files. It also draws a clear boundary ('fast solver stage, not a way to build or bypass review'), which separates it from preparation/review siblings. It never names diana_solve directly, so the sibling distinction is implied by workflow stage rather than explicit.

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?

States the mutual-exclusion rule crisply ('exactly one baseline_id or campaign_id is required') and gives the preconditions for each path: byte-identical baseline files, or complete approved parameter values plus a semantic change manifest. restart_ff is tied to concrete scenarios (restarts, RESTOR, stand-alone *REDUCT/*ELIQUE/*ECREEP). What is missing is an explicit 'for X use diana_solve instead' routing statement against the most confusable sibling.

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

Deploy Server