Hydrata MCP Server

Official

by Hydrata

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Get a scenario's state, inputs and price

get_scenario

Read-onlyIdempotent

Retrieve a scenario's compact state, including computed status, inputs, cost estimate, and run details. Use it to check build readiness and pricing without fetching raw detail.

Instructions

Get a scenario's COMPACT state: its computed_status, inputs, estimate and price.

Returns a compact record, never the raw ~50 KB detail: scenario_id, computed_status, mesh_triangle_count_estimate and its _breakdown, latest_run_is_valid, the latest run's run_id, run_status, error_message, user_message, status_detail and mesh_triangle_count — plus what the scenario IS and what it will cost: name, description, project, resolution, duration, the input row ids (terrain, boundary, friction, inflow, rainfall, building, mesh_region, culvert), compute_cost_estimate (USD), vcpu_hours_estimate, and inflow_anchor_mismatch (null unless an inflow series starts after the model does: the model gets zero flow from that series over the lead-in gap before its first sample), and hydrology_check (when Hydrata sends it: for each inflow and rainfall feature, the series that drives it, its peak and volume, and structured warnings — repeat those numbers to the user, never your own), and unbound_series with a say_to_user warning when the project holds a rainfall or flow series that no inflow or rainfall feature uses (the model ignores it: tell the user and ask which input it belongs to).

The computed_status field (there is NO status key on a scenario) is derived from the latest run and will be one of: created, building, built, queued, computing, processing, complete, error, or cancelled — created also means no run exists yet. A scenario must be built before it can be run. latest_run_is_valid is false after any edit since the last build. unreviewed_inputs lists the inputs written by an agent key that the user has not reviewed at their current content (kind, layer_id, title, feature_count, the grant that wrote it, authored_method (the agent's own account of how it made the input, when it gave one), reopened when an edit undid an earlier input review): while it is not empty, build and run are refused UNREVIEWED_INPUTS. Only the user reviews, in the browser — poll this tool every 30-60 s after giving them the review link. A non-member reading a public project's scenario gets a reduced record: the fields the server withholds (the input ids, the price, inflow_anchor_mismatch) are ABSENT here rather than reported as null — "withheld" is not "no terrain, no cost" — while the run-state keys, computed_status among them, read null.

No presigned S3 URL is returned by any read tool (each is a 6-hour capability): results stay viewable through a run's gn_layer_* WMS entries — use get_run for the full run record.

Input Schema

Name	Required	Description	Default
`project_id`	Yes	The project ID
`scenario_id`	Yes	The scenario ID

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Oct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Far exceeds what readOnlyHint/idempotentHint convey: it enumerates computed_status values, explains latest_run_is_valid semantics, discloses the reduced record for non-members (fields ABSENT rather than null, run-state keys null), and states no read tool returns a presigned S3 URL. These are exactly the behaviors an agent cannot infer from annotations or schema.

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 compact-state framing, and every clause carried content (status enum, withholding, review gating, anchor mismatch). It is still a very long, clause-heavy block — several sentences run past 60 words, which costs some scannability.

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?

Even though an output schema exists, the description supplies the interpretation the schema cannot: null vs absent under reduced access, what computed_status values imply, and how to relay hydrology_check and unbound_series to the user. Nothing needed to call or interpret it is missing.

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?

Schema coverage is 100% and both parameters are simple ids documented in the schema; the description adds nothing about project_id/scenario_id. Baseline 3 applies when the schema already does the work.

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?

Opens with a specific verb+resource+scope ("Get a scenario's COMPACT state") and immediately contrasts it with the raw ~50 KB detail, which together with the explicit pointer to get_run distinguishes it from the sibling tools get_run, list_runs and get_run_status.

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?

Gives concrete operating guidance: poll every 30–60 s after handing over the review link, build/run are refused while unreviewed_inputs is non-empty, and "use get_run for the full run record" names the alternative and the condition that selects it.

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