Multi-server MCP ecosystem for SWMM hydrological modeling with tools for model building, calibration, climate data, GIS processing, parameter management, network analysis, plotting, simulation execution, and uncertainty quantification.
Single tool 'build_inp' with complete schema definition and basic description. However, description is extremely brief (94 characters), parameter descriptions are minimal and lack constraints, no error handling guidance, and no documentation of output structure. The tool performs a complex multi-file assembly operation (WRITE risk) without confirmation, dry-run, or recovery guidance. Tool name 'build_inp' is domain-specific but lacks clarity on what 'INP' means and when to use this vs alternatives. Parameter descriptions are often one-word (e.g., 'Path to subcatchments CSV file') without format constraints, examples, or validation hints. No evidence of output schema documentation. Overall definition quality is below baseline for production tool adoption.
Assemble runnable SWMM INP + manifest from subcatchment/params/network/climate inputs.
Tool description is 94 characters, below rubric baseline (194 chars avg). Lacks explanation of WHEN to call build_inp, WHAT it does in context of SWMM workflows, and ANY guidance on prerequisites or expected input structure.
Parameter descriptions are minimal (e.g., 'Path to subcatchments CSV file') with NO format constraints, NO validation hints, NO cardinality guidance, and NO examples of valid input. LLM cannot infer CSV schema, required columns, or error recovery.
Tool performs WRITE operation (assembling runnable files) without dry-run, confirmation, or recovery guidance. Agents cannot safely preview results before execution. No documentation of side effects or rollback options.
Output schema is NOT documented. Tool returns 'Assemble runnable SWMM INP + manifest' but LLM does not know: what fields? what structure? can downstream tools consume manifest directly? are there error codes or warnings?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | 2026-07-28+ | v2 |
No error handling guidance. If a CSV is malformed, network file cannot be read, or output path is not writable, tool provides no actionable recovery path. LLM cannot disambiguate retryable vs fatal errors.
Parameter 'defaultGageId' is poorly named. Does it apply only when rainfallJsonPath/raingageJsonPath are absent? Must a gage ID always exist in the network JSON? Undocumented dependency invites misuse.
Optional parameters (rainfallJsonPath, raingageJsonPath, timeseriesTextPath, configJsonPath, defaultGageId, waterQualityJsonPath) are not marked as optional in descriptions. What happens if they are omitted? What are the defaults? Must the user understand SWMM INP format to use this tool?