Skip to main content
Glama

mz_run

Run MIKE Zero simulations headlessly, returning a job ID for tracking progress and logs.

Instructions

无界面启动一次 MIKE Zero 模拟,返回作业 id。

默认后台运行,用 mz_progress / mz_job_status / mz_job_log 跟踪进度。

两种入口(实测 MIKE Zero 2023):

  • direct=False(默认)走 MzLaunch.exe:支持 -e/-mpi/-gpu/-y/-z, 但模拟结束后会删掉 ._spi_ 进度文件(本服务会先归档)。

  • direct=True 直接调引擎 exe(如 MIKE11.exe / FemEngineHD.exe):开关按引擎 自己的语法拼装,._spi_ 跑完仍保留。不支持 -mpi/-gpu/-z。

Args: setup: setup 文件绝对路径。 engine: 可选,显式指定引擎 exe(如 MIKE11.exe);不传则由 MzEngines.cfg 按扩展名自动选择。 direct: True 时绕过 MzLaunch,直接调用引擎。 engine_flag: 走 MzLaunch 时指定引擎的参数名,默认 "-e"。 silent: 走 MzLaunch 时传未文档化的 -run(实测可省,非必要不要开)。 exit_when_done: 走 MzLaunch 时传 -x,模拟结束后退出启动器。 mpi: 子域数,传 -mpi N(需该引擎支持 MPI)。 gpu: GPU 卡数,传 -gpu N。 priority: CPU 优先级,传 -y 1..4(1 低,4 高于正常)。 extra_args: 追加的原始命令行参数。 result_dir: 走 MzLaunch 时传 -z 指定结果目录。 year: 可选,指定 MIKE Zero 年份。 wait: 是否同步等待结束(长时间模拟建议保持 False)。 timeout: wait=True 时的等待上限(秒)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gpuNo
mpiNo
waitNo
yearNo
setupYes
directNo
engineNo
silentNo
timeoutNo
priorityNo
extra_argsNo
result_dirNo
engine_flagNo-e
exit_when_doneNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries full behavioral burden, and it does so thoroughly: it discloses background execution, return of a job id, the side effect that MzLaunch deletes `._spi_` progress files (archived first), direct-mode preservation of those files, unsupported flags in direct mode, and wait/timeout behavior. This materially exceeds what the schema alone provides.

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 structured: a one-line purpose, a short tracking pointer, a compact two-mode comparison, and then a clean bullet-style Args list. Every sentence adds operational value, and the most decision-critical information 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?

For a 14-parameter, side-effect-heavy launch tool with no annotations and no output schema, this description is unusually complete. It covers what is returned, background behavior, progress tracking, mode-specific differences, version caveat, parameter effects, and wait/timeout semantics. An agent has enough to call the tool correctly in most real scenarios.

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%, so the description must compensate, and it does: every one of the 14 parameters is given meaningful semantics, including defaults, exact CLI flags they map to, and conditional effects (e.g., direct mode disables -mpi/-gpu/-z). This is far beyond raw schema property names.

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 precise statement: '无界面启动一次 MIKE Zero 模拟,返回作业 id' – a specific verb, resource, and observable result. It also orients the agent relative to sibling tracking tools by naming mz_progress / mz_job_status / mz_job_log for follow-up, which helps differentiation.

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?

The description clearly explains the default background execution model and when to use the progress/job-status tools, and it gives detailed guidance on choosing direct=False vs direct=True. It does not explicitly contrast with mz_run_batch or say 'do not use this when...', so it falls just short of fully explicit alternative routing.

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