Hydrata MCP Server

Official

by Hydrata

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Wait for a terrain import

get_terrain

Read-onlyIdempotent

Poll a project's terrain import until it reaches ready or error, bounded by a timeout. Returns the outcome, last status, phase, poll count, elapsed time, and full terrain record.

Instructions

Poll a terrain's import until it is ready (or error), bounded by timeout_seconds.

Returns outcome — exactly one of ready, error, timed_out, not_found (the project has no terrain yet; an unknown terrain_id is an API 404 error instead) — plus the last status seen (creating → styling → ready | error) and phase (that status, or not_found; never empty), polls, elapsed_seconds and the full terrain record (its gn_layer is the published elevation dataset pk once ready). An import takes minutes to tens of minutes (the SAME 32 MB 1 m DEM measured 4.5 min once and 26 min once — the worker's S3 download speed dominates), so timed_out is normal and NOT a failure: keep calling with the same arguments while status is still creating/styling; several calls in a row is expected. error is terminal — the import failed and no default input rows were seeded; upload a corrected GeoTIFF as a new terrain.

ready is written by the import task; the project's default input rows (Boundary 01, Friction 01, Inflow 01, Rainfall 01, Building 01, MeshRegion 01, one GeoNode layer each) are seeded by the NEXT task in the chain and appear over the following ~30 s. Poll the input-layer list until it is non-empty before attaching your own layer to a default row.

Input Schema

Name	Required	Description
`project_id`	Yes	The project ID
`terrain_id`	No	The terrain ID from finalize_terrain_upload. Omit to follow the project's newest terrain.
`timeout_seconds`	No	How long this call keeps polling before it returns `timed_out` (default 180, ceiling 200 — claude.ai cuts a tool call at 240 s). 0 = one status read, no waiting.
`poll_interval_seconds`	No	Seconds between polls (default 5)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.2.0Oct 30, 2026

changedInput schema / properties / timeout_seconds / default
```
Previous value: -240New value: +180
```

changedInput schema / properties / timeout_seconds / description

Previous value: -"How long this call keeps polling before it returns `timed_out` (default 240, ceiling 280 — the prod /mcp/ proxy cuts a call at 300 s). 0 = one status read, no waiting."New value: +"How long this call keeps polling before it returns `timed_out` (default 180, ceiling 200 — claude.ai cuts a tool call at 240 s). 0 = one status read, no waiting."

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 the readOnly/idempotent annotations: it enumerates the exact `outcome` values, distinguishes `not_found` (project has no terrain) from an unknown terrain_id (API 404), and discloses realistic durations (4.5–26 min) so the agent can calibrate polling behavior. It also warns that `ready` precedes default input-row seeding by ~30 s.

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 purpose and outcome enum, then state-machine and failure semantics. Dense but well ordered; the 32 MB DEM timing anecdote and the enumerated default input rows are slightly verbose but serve a real calibration purpose.

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 covers the terminal states, the non-obvious `not_found` case, the seeding lag, and retry semantics — everything an agent needs to poll correctly without guessing. Nothing material is missing for a read-only polling tool.

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 the schemas already document project_id, terrain_id (omit → newest terrain), timeout_seconds ceiling and 0 = single read, and poll_interval. The description reinforces semantics (timeout bounding, same-arguments retry) but adds little the schema does not already say, so the baseline 3 applies.

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 precise verb+resource+termination condition: 'Poll a terrain's import until it is `ready` (or `error`), bounded by timeout_seconds.' It is clearly distinct from finalize_terrain_upload (which it implicitly follows) and from generic status tools like 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?

Explicitly tells the agent that `timed_out` is normal and NOT a failure, to keep calling with the same arguments while status is creating/styling, and that `error` is terminal requiring a re-upload. It also gives the follow-up ritual: poll the input-layer list until non-empty before attaching a layer.

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