Hydrata MCP Server

Hydrata publishes a Model Context Protocol (MCP) server so an AI assistant can read your flood modelling projects and drive simulation runs on Hydrata Cloud.

Preview

The server is published and running, but it is not open to external accounts yet. There is no way to connect your own Hydrata account to it today, so the tools below are a preview of the interface rather than something you can wire into your editor. Per-user access is planned.

Endpoint: https://hydrata.com/mcp/ Transport: StreamableHTTP Source: github.com/Hydrata/hydrata-mcp-server Registry: registry.modelcontextprotocol.io, published as com.hydrata/hydrata-mcp-server

Tools

Every tool call needs the caller's own hydrata.com credential. The server holds no identity of its own: a tool call carries the caller's HTTP Basic credential, which the server forwards unchanged to the Hydrata REST API, so results are scoped by the real user's project permissions and the audit trail names them. Browsing the catalog (initialize, tools/list) needs no credential. The server is not yet open to external accounts, so there is no client-side setup recipe here; per-user access is planned.

Version 0.2.0 exposes seventeen tools: nine that read projects and scenarios, start a run on a scenario that has already been built and follow that run to completion, and eight that build a model from terrain and input layers the assistant has already uploaded. No tool accepts file contents inline: the assistant moves the bytes itself and hands the server a key or an upload id.

Tool	What it does
list_projects	List the ANUGA simulation projects the caller can see, paginated
get_project	Get one project: name, projection, base map and its scenarios
get_scenario	Get one scenario, including the status computed from its latest run
start_simulation	Start a run for a scenario that is already in built status
get_run_status	Lightweight status poll: status, percent complete, estimated time remaining
get_run	Full run record: timing, compute details, mesh info, result log
cancel_run	Cancel a run still in built, queued or computing status
retry_run	Reset an errored run and rebuild its package, reusing the same run id
list_runs	List the runs across a project, optionally filtered by status
create_project	Create an ANUGA project with a name and EPSG projection
presign_terrain_upload	Return a presigned URL and key so the assistant PUTs the terrain GeoTIFF itself; no file bytes pass through MCP
finalize_terrain_upload	Register the uploaded terrain; creates the project's default boundary, friction, inflow, rainfall and mesh-region rows
get_terrain	Poll the terrain until it is ready
create_time_series	Create a time series from {"rowData": [...]} for an inflow or rainfall
attach_input_layer	Attach a GeoJSON dataset the assistant already uploaded as the project's boundary, friction, inflow, rainfall, structure or mesh-region layer; breakline and culvert are refused because culvert flow is not conveyed
create_scenario	Create a scenario and return its mesh-triangle estimate
build_scenario	Build the scenario mesh; reports the estimate first, needs confirm=true above 100,000 triangles, and surfaces the server's 422 MESH_TOO_LARGE response verbatim

Editing an existing scenario is not part of the tool set. create_scenario and build_scenario create and mesh a new one; any other change to a scenario is made in the browser, and the server drives it from there.

What a run looks like through the tools

A run moves through built, queued, computing, processing and then complete. Poll get_run_status while it is in flight, and read get_run once it finishes. retry_run applies only to a run that ended in error.

For the same workflow in the browser, start with the Getting Started tutorial. For the HTTP interface underneath both, see the REST API.