The mike-plus server lets you inspect, edit, run, and analyze MIKE+ hydraulic models entirely headless — no GUI required — using natural language through an AI agent.
Model Inspection (requires MIKE+ license)
mike_model_info — Get an overview of a .sqlite model: active simulation/scenario, unit system, simulations, scenarios, and element counts.
mike_get_values — Read parameter values from any MIKE+ table (e.g., pipe diameters, Manning roughness), optionally filtered by element MUIDs.
Model Editing (requires MIKE+ license)
mike_set_values — Modify parameter values for specific elements; returns before/after values for audit. Always use on a copy — changes are permanent.
Running Simulations (requires MIKE+ license)
mike_run — Execute a MIKE+ 1D simulation headlessly, returning result file paths (.res1d) and a parsed QA status from the engine log.
Results Analysis (no license needed)
mike_results_list — List contents of a .res1d file: available quantities, element counts, and simulation time range.
mike_results_summary — Get per-quantity peak summaries (value, element, chainage, time); supports skipping warm-up hours.
mike_results_read — Extract a single time series for a quantity at a specific element, downsampled to a configurable number of points.
Plotting & Visualization (no license needed)
mike_plot_rain_flow — Stacked rainfall-runoff figure from a .res1d, with optional rainfall from a .dfs0 file.
mike_plot_timeseries — Single-panel time-series plot for any quantity at any element.
mike_plot_network — Network layout map (pipes as lines, nodes as points) for a spatial overview.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mike-plus run the baseline simulation and show the peak flow summary"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A headless, natural-language-driven, automated modelling workflow for MIKE+. Skills + an MCP server for Claude Code, Codex, Hermes, or OpenClaw: describe a goal in plain language and the agent inspects, edits, runs, reads, and plots a MIKE+ model. Automated modelling and analysis, end to end, without ever opening the GUI.
Need a model to run? SWMMCanada builds one anywhere in Canada. It is the upstream, open-data model builder for this agentic workflow: draw an area on a map and it assembles a ready-to-run stormwater model from Canadian open data (real municipal storm networks for 8 cities, synthesized everywhere else), giving the agent a real network to run, edit, read, and plot. Try the hosted demo with no install at swmm.h2ox.me, or see the project at h2ox.me.
Experimental / pre-release. One MCP server + skills wrapping DHI's Python stack (
mikeplus/mikeio/mikeio1d). Verified end to end on the MIKE+ 2026Sirius_RTCexample. Sibling of agentic-swmm-workflow.
It is the AI era. You don't wire this up by hand. Paste this to your AI coding agent (Claude Code, Codex, Hermes, OpenClaw):
Install "Agentic MIKE+" for me: an MCP server + skills to drive MIKE+ headless.
1. Clone https://github.com/Zhonghao1995/Agentic-MIKE-Plus and skim its README.
2. With Python 3.11 x64 (mikeplus needs 3.9-3.11, not 3.12+):
py -3.11 -m venv .venv
.venv\Scripts\python.exe -m pip install -r requirements.lock
.venv\Scripts\python.exe -m pip install -e ".[run]"
(read/plot only, no license: drop the lock and use `pip install -e .`)
3. Register with me (Claude Code):
claude mcp add mike-plus -- "<abs-repo>\.venv\Scripts\python.exe" -m mikeplus_mcp.server
(Codex / Hermes / OpenClaw: copy config/mcp.sample.json)
4. Copy skills/* into ~/.claude/skills/, then run scripts/smoke_test.py (should find 18 tools).
5. Tell me the tools and which need a MIKE+ license (run/edit/import do; read/plot/compare don't).Needs Python 3.11 (x64). Two install profiles:
Read & plot. License-free and cross-platform: pip install -e . (no mikeplus).
Run & edit too. Windows + a licensed MIKE+ 2026: pip install -e ".[run]" (or pip install -r requirements.lock for the exact pinned environment).
mikeplus is an optional [run] extra, so teammates who only read results or make figures install nothing license-bound.
Related MCP server: SWMM-MCP
Natural-language-driven. Describe the task in plain words; the agent plans and runs it: no scripting, no GUI clicking. (A sub-agent did this autonomously.)
Fully headless. Runs with no GUI, on a workstation, a server, in CI, or under an agent. Built for batch and scenario automation.
MCP-native and portable. One server speaks the Model Context Protocol; works with Claude Code, Codex, Hermes, or OpenClaw via a single config line, and installs with pip.
Low barrier to share. Reading results and plotting need no MIKE+ license; only running or editing does. Teammates analyse model output with nothing but pip install.
Reproducible & tested. Deterministic tools, structured-JSON output, a pinned lockfile, and a license-free unit-test suite in CI, verified on a real model, not a chat-to-model black box.
Engine-agnostic and extensible. Results use a common schema (ready to sit beside SWMM and LSTM); add a tool or skill by dropping in a file.
Skills (markdown playbooks) tell the agent when and how; the agent calls MCP tools; each tool runs in an isolated worker subprocess that imports only mikeplus or mikeio*: the two cannot share a process. The server itself imports neither.
agent -> reads skills/*.md -> calls MCP tools -> workers (mikeplus / mikeio1d)mike-plus)Tool | Does | License |
| model overview: simulations, scenarios, model type, element counts | yes |
| activate an existing scenario (verified by re-opening the model) | yes |
| read / change parameters (e.g. pipe diameter) | yes |
| run a simulation headless, return | yes |
| import an EPA SWMM (or EPANET) | yes |
| list contents / peaks / one time series | no |
| which nodes flood: peak water level vs ground level, ranked | no |
| baseline vs scenario: delta peak / volume / timing, RMSE, NSE; or every element ranked by change | no |
| stacked hydrograph / series / network map | no |
| overlay of two runs / longitudinal profile (bed, crown, ground, max water level) | no |
| rainfall CSV to a MIKE+ | no |
| provenance manifest: model, inputs, edits, run QA, results, figures, each with sha256 | no |
Ten skills orchestrate them: mike-end-to-end (the SOP: modes, run directory, stop rules, QA gates), mike-model, mike-params, mike-runner, mike-import, mike-results, mike-compare, mike-plot, mike-rain, mike-audit.
Install the skills into any skills-aware agent (Claude Code, Codex, OpenCode, …) in one command, no clone needed:
npx skills add Zhonghao1995/Agentic-MIKE-Plus # all 10; add --list to preview, or --skill <name> for oneSirius_RTC (MIKE 1D, 568 nodes, 576 links)Full evidence (commands, outputs, and the honest license boundary) is in docs/verification.md.
The engine-agnostic core is covered by a license-free test suite (no MIKE+ / mikeplus needed) that also runs in CI:
pip install -e . # read/plot core (add ".[run]" for run/edit)
pip install pytest
pytest # ~0.5 s, no license requiredThe tests pin the result schema, the res1d column matcher, the engine-log QA parser, the compare / rain / manifest / SWMM-inp helpers, and tool discovery, so a change can't silently break them. Add a tool or skill by dropping a file under mikeplus_mcp/tools/ or skills/ (auto-discovered), and ship a test with it.
MIT © 2026 Zhonghao Zhang, University of Victoria. Built on DHI's mikeplus / mikeio / mikeio1d and the Model Context Protocol. MIKE+ is a product of DHI; running models requires a valid DHI license.
Read parameter values from a MIKE+ table (e.g. msm_Link, msm_Node, msm_Catchment) for the given columns and optional element MUIDs. Read-only. Needs MIKE+ + license. Use this to identify current parameter values.
| Name | Required | Description | Default |
|---|---|---|---|
| sqlite | Yes | ||
| table | Yes | Table name, e.g. 'msm_Link', 'msm_Node', 'msm_Catchment'. | |
| columns | No | Columns to read, e.g. ['Diameter','Manning']. Omit for all. | |
| muids | No | Optional element ids to filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description declares read-only behavior and license requirement, but lacks details on error handling, performance, or edge cases. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no wasted words. Efficiently communicates core information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter read tool with no output schema, description covers purpose, parameters, read-only nature, and license. Lacks error handling and return format, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%; description adds context for table examples and optional muids, but does not significantly enhance parameter meaning beyond what schema provides. Adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool reads parameter values from MIKE+ tables, specifying the resource (e.g., msm_Link) and action (read). It distinguishes from siblings like mike_set_values by implying a read-write pair.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states read-only and license requirement. Provides usage advice ('Use this to identify current parameter values') but does not explicitly contrast with write alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a MIKE+ .sqlite model and report the active simulation/scenario/model, unit system, the list of simulation setups (msm_Project), scenarios, and element counts (nodes/links/catchments). Read-only. Needs MIKE+ + license.
| Name | Required | Description | Default |
|---|---|---|---|
| sqlite | Yes | Path to the MIKE+ .sqlite model database. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It explicitly states 'Read-only' as a key behavioral trait and mentions license requirement. However, it does not describe error behavior (e.g., missing file, invalid model) or output format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (one sentence with list) and front-loaded with action and output. Could be slightly better structured with bullet points, but overall efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one input and no output schema, description adequately lists returned information categories. It is missing explicit output structure or format, but given tool complexity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description 'Path to the MIKE+ .sqlite model database.' The description adds no significant additional meaning beyond specifying it's a .sqlite file. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a MIKE+ .sqlite model and reports specific metadata (active simulation, unit system, simulation setups, scenarios, element counts). It distinguishes itself from sibling tools like mike_run or mike_get_values by focusing on model info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes read-only nature and license requirement, but does not explicitly mention when to use this tool vs siblings (e.g., mike_get_values for fetching values). The context is clear but lacks explicit exclusion or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a network layout map of a MIKE+ model from a .res1d — reaches/pipes as lines, nodes as points, equal-aspect, house style. Good for an overview figure. No license needed.
| Name | Required | Description | Default |
|---|---|---|---|
| res1d | Yes | ||
| out_png | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It lacks details on side effects (e.g., file overwriting), error handling for invalid inputs, or limitations. Only mentions 'no license needed' as a behavioral note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three sentences, each adding value: main action, use case, and license note. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description covers the core purpose but omits important context such as error behavior, output format details, and parameter constraints. It is adequate for simple usage but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions '.res1d' as input and implies 'out_png' as output, but does not explicitly define each parameter or provide format/syntax details beyond the schema's basic names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a network layout map of a MIKE+ model from a .res1d file, specifying visual elements (lines for pipes, points for nodes) and style (equal-aspect, house style). It effectively distinguishes from sibling tools like mike_plot_timeseries which handle time series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is 'good for an overview figure' and mentions 'no license needed', providing context for appropriate use. However, it does not explicitly exclude cases where other tools should be used or mention prerequisites like file existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a stacked two-panel rainfall-runoff figure (rain inverted on top, flow on bottom) in the house style. Flow comes from a .res1d element; rainfall optional from a .dfs0. No license needed.
| Name | Required | Description | Default |
|---|---|---|---|
| res1d | Yes | ||
| element | Yes | Reach/link or node id for the flow series. | |
| quantity | No | Flow quantity (default 'Discharge'). | |
| rain_dfs0 | No | Optional rainfall .dfs0 for the top panel. | |
| out_png | Yes | Output PNG path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that no license is needed and that rainfall is optional. However, it does not detail behavior such as whether the file is overwritten, time alignment handling, or error conditions for missing rain_dfs0. For a plotting tool, these are not critical but a bit more detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the main purpose and adding necessary usage details. Every word serves a purpose; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (5 params, 3 required, no nested objects, no output schema), the description covers the core aspects: data sources, optionality, and licensing. The mention of 'house style' is vague but acceptable for an internal tool. It does not include error handling or data format expectations, but for a plot tool these are secondary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% (4 of 5 parameters have descriptions), so baseline is 3. The description adds context linking res1d to the source file and element to the flow series, but does not provide additional details beyond the schema. For example, the schema already says element is 'Reach/link or node id'. The description does not compensate for the missing description of the res1d parameter in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool renders a 'stacked two-panel rainfall-runoff figure' with specific details (rain inverted on top, flow on bottom, house style). Verb 'Render' and resource 'rainfall-runoff figure' are specific, and the description distinguishes it from sibling tools like mike_plot_timeseries which plots generic timeseries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that flow comes from a .res1d element and rainfall is optional from a .dfs0, giving clear context for when to use this tool. While it does not explicitly state when not to use alternatives, the contrast with sibling tools like mike_plot_timeseries is implicit. The 'No license needed' note is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a single-panel time-series plot (a quantity at an element) in the house style. No license needed.
| Name | Required | Description | Default |
|---|---|---|---|
| res1d | Yes | ||
| quantity | Yes | ||
| element | Yes | ||
| out_png | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses one behavioral trait ('no license needed') but omits details on side effects (e.g., file overwriting), output format, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences front-load the action and key condition. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description provides the essential purpose but lacks details on output expectations (e.g., that it saves a PNG) and examples. It is minimally complete for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions 'quantity at an element' and 'single-panel time-series plot', hinting at parameter roles, but does not explicitly describe each parameter (res1d, quantity, element, out_png) beyond these cues.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it renders a single-panel time-series plot, specifying 'house style' and 'no license needed'. It distinguishes from sibling tools like mike_plot_network and mike_plot_rain_flow by focusing on time-series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'no license needed' as a precondition, but lacks explicit guidance on when to use this tool versus alternatives. The name and context imply timeseries plotting, but no direct comparisons or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List what is inside a MIKE+ .res1d: quantities (WaterLevel/Discharge/...), element counts (nodes/reaches/structures/catchments) with sample ids, and the time range. No license needed.
| Name | Required | Description | Default |
|---|---|---|---|
| res1d | Yes | Path to a .res1d file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool lists contents (non-destructive), specifies scope (quantities, element counts, time range), and notes 'No license needed'. No behavioral traits like side effects or rate limits are mentioned, but for a read-only list tool, this is sufficient. No contradiction with missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no extraneous words. Every part contributes to understanding the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one parameter, no output schema), the description adequately covers what the tool lists and returns (quantities, element counts, time range). Missing details like output format (list vs. dictionary) but likely implied; still sufficient for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (single parameter with description). The tool description adds no additional meaning beyond the schema's parameter description ('Path to a .res1d file.'). It does not provide format, constraints, or alternatives, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list') and the resource (MIKE+ .res1d file contents), specifying the types of information returned: quantities, element counts with sample ids, and time range. This distinguishes it from sibling tools like mike_get_values or mike_results_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over siblings. The description mentions 'No license needed' as a prerequisite, but does not explain when to choose mike_results_list versus mike_get_values, mike_results_summary, or other list-oriented tools. Implied usage but no clear alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract one time series (a quantity at an element) from a MIKE+ .res1d as times+values (downsampled to max_points). No license needed.
| Name | Required | Description | Default |
|---|---|---|---|
| res1d | Yes | ||
| quantity | Yes | e.g. 'Discharge' or 'WaterLevel'. | |
| element | Yes | Element id (node id, or reach/link id, optionally with chainage). | |
| max_points | No | Cap on returned points (default 5000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose read-only nature and potential side effects. It mentions downsampling and license requirement but omits error behavior or whether it modifies data. The information is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and provides key details without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool returns data but the description lacks details on the output format beyond 'times+values'. There is no output schema, so more specifics on the structure would be beneficial. The context is partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so description adds some value. It clarifies that max_points caps returned points (default 5000) and mentions 'no license needed' but does not explain the res1d parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts one time series from a MIKE+ .res1d file, specifying the output format and downsampling. It distinguishes from sibling tools like mike_get_values and mike_results_list by focusing on a single time series extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as mike_get_values or mike_results_summary. The note 'no license needed' is a positive but does not clarify usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-quantity peak summary (peak value, element, chainage, time) from a MIKE+ .res1d. No license needed. NOTE: this is the GLOBAL max over the whole run, which can fall in the warm-up/initial-condition period (a base-flow value near t=0) rather than the storm peak — pass skip_hours to exclude an initial window and always check peak_time.
| Name | Required | Description | Default |
|---|---|---|---|
| res1d | Yes | ||
| quantities | No | Optional subset, e.g. ['Discharge','WaterLevel']. | |
| skip_hours | No | Exclude the first N hours (warm-up) before finding peaks. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses that the tool identifies the global maximum over the entire run, which may fall in the warm-up period. This critical behavioral nuance is well explained, though return format details are implied rather than explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only two sentences and a note. All information is front-loaded and relevant, with no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and no annotations, the description provides adequate completeness by explaining the output's nature and the warm-up caveat. However, it could be more detailed about the output format or error cases, keeping it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema by explaining the purpose of skip_hours (excluding warm-up) and quantities (per-quantity summary). Schema coverage is 67%, and the description fills some gaps, especially for the res1d parameter by specifying the file type (.res1d).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a per-quantity peak summary with specific fields (peak value, element, chainage, time) from a MIKE+ .res1d file. This distinguishes it from sibling tools like mike_results_list or mike_results_read that serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical guidance on warm-up periods and instructs using skip_hours to exclude initial windows, advising to always check peak_time. While it does not explicitly compare to alternatives, the note offers clear usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a MIKE+ simulation headless via the MIKE 1D engine. Runs the model's active simulation unless 'simulation' is given. Returns the result file paths plus the engine log tail. Needs MIKE+ installed + a valid license. ALWAYS run on a COPY of the model (mikeplus has no undo).
| Name | Required | Description | Default |
|---|---|---|---|
| sqlite | Yes | Path to the MIKE+ .sqlite to run (use a copy). | |
| simulation | No | Optional simulation setup id (msm_Project MUID). Default: the active simulation. | |
| timeout_s | No | Max seconds to wait for the engine (default 1800). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavioral traits: runs headless, returns result file paths and engine log tail, requires MIKE+ and license, and warns of no undo. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the main action, no redundant information. Efficiently covers purpose, usage, and warnings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simulation tool with 3 parameters and no output schema, the description fully covers inputs, safety (run on copy), return info (file paths + log tail), and prerequisites (license).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning: sqlite path should be a copy, simulation is optional with default, timeout default 1800. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run a MIKE+ simulation headless via the MIKE 1D engine', specifying the verb, resource, and mode. It distinguishes from sibling tools that focus on plotting, retrieving values, or model info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions using the active simulation by default and the option to specify one, plus a strong warning to always run on a copy. Does not explicitly compare to alternatives, but siblings are distinct in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set parameter values in a MIKE+ table for specific element MUIDs (e.g. change a pipe Diameter or Manning roughness). Returns before/after for the affected rows. MUTATES the database — ALWAYS use a copy. Needs MIKE+ + license. Pass 'muids' to scope the change; set all=true only when you intend to change every row.
| Name | Required | Description | Default |
|---|---|---|---|
| sqlite | Yes | ||
| table | Yes | ||
| values | Yes | Column-value pairs to set, e.g. {"Diameter": 0.4}. | |
| muids | No | Element ids to update. | |
| all | No | Update ALL rows (only if muids omitted). Use with care. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses mutation, return of before/after, requirement to use a copy, and license needs. No annotations exist, so description carries full burden and provides essential behavioral context beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: main purpose, return info, then warnings and usage. Every sentence adds value without redundancy. Front-loaded with action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main usage, mutation warning, and return type (before/after). Lacks detail on error handling or return format details, but adequate for a mutation tool with 5 parameters and no output schema given the clear warnings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning to muids (scope the change), all (update all rows, use with care), and values (column-value pairs). However, sqlite and table parameters are not elaborated beyond schema. With 60% schema coverage, description partially compensates but leaves some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'parameter values in a MIKE+ table' with specific scope (element MUIDs). Examples (pipe Diameter, Manning roughness) clarify the function. It distinguishes from sibling tools like mike_get_values by specifying mutation and return of before/after.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Set parameter values'), warns about mutation ('ALWAYS use a copy'), and distinguishes between scoped updates (muids) and bulk updates (all=true). Also notes prerequisite: 'Needs MIKE+ + license'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0mike_get_valuesmike_model_infomike_plot_networkmike_plot_rain_flowmike_plot_timeseriesmike_results_listmike_results_readmike_results_summarymike_runmike_set_valuesEach tool has a clearly distinct purpose: reading/setting parameters, model info, three plot types, results listing/reading/summary, and simulation execution. No overlapping functionality.
All tools follow a consistent 'mike_verb_noun' pattern (e.g., get_values, plot_network, results_list). The verbs are descriptive and uniformly formatted.
10 tools is well within the ideal 3-15 range. The number covers the essential operations for MIKE+ modeling without being excessive.
The toolset covers the core workflow: model info, parameter read/write, simulation run, and results analysis/plotting. Minor gaps include lack of tools for structural model editing or scenario management, but for the intended purpose it is solid.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Automated, calibrated SWAT+ watershed modeling and national hydrologic datasets for the U.S.
Conversational what-if simulation: build, diagnose and compare Petri-net models; CC0 catalog.
Multi-expert decision intelligence with transparent synthesis and auditable workflows.
Give your AI agents the tools to build, manage, and run automation workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Zhonghao1995/Agentic-MIKE-Plus'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
