Hydrata MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Fetch terrain from a Hydrata source

create_terrain_from_source

Fetches a DEM from a selected Hydrata terrain source for a project, reprojects and publishes it, seeds default input rows, and polls the import until ready or timed out.

Instructions

Have Hydrata fetch a terrain from one of its own sources, then wait for the import (like get_terrain).

Use a key from list_terrain_sources. Hydrata fetches, reprojects and publishes the DEM and seeds the project's default input rows; the DEM's datum is stamped by the source. The result is get_terrain's envelope (outcome ready | error | timed_out, terrain, polls) plus terrain_source: the source's key, name, resolution_m, licence, credit and vertical_datum. timed_out is normal for a large area: keep calling get_terrain(project_id, terrain_id). A refusal (the box is over the source's size cap, the source has no data there, an unknown source) comes back as outcome: refused with the reason in say_to_user and nothing is created.

Input Schema

Name	Required	Description
`bbox`	Yes	The site as [min_lon, min_lat, max_lon, max_lat] in WGS84 degrees
`title`	No	Terrain title (default: the source name and box)
`source`	Yes	A source `key` from list_terrain_sources, e.g. `ga_lidar_5m` or `copernicus_glo30`
`project_id`	Yes	The project ID (the key needs Contributor rights; a launch-level key since the import can start AWS Batch)
`timeout_seconds`	No	How long this call keeps polling the import before it returns `timed_out` (default 180, ceiling 200). 0 = start it and return at once; then call get_terrain.
`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.

Addedv0.2.0Oct 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) by disclosing side effects: Hydrata fetches, reprojects, publishes the DEM and seeds the project's default input rows, with datum stamped by the source. It also explains that `timed_out` is normal for large areas and that a refusal creates nothing and puts the reason in `say_to_user`.

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 action, then the prerequisites, then the return shape and failure path — a sensible order with little filler. The return-envelope sentence partially restates what the existing output schema already provides, which costs some tightness.

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?

For a write operation with an output schema, it covers the things an agent still needs: contributor/launch-level key rights, that the import can start AWS Batch, the timeout-as-polling contract, and the refused outcome path. Nothing material is missing for correct invocation or follow-up.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already defines bbox, source, timeout_seconds and poll_interval_seconds. The description still adds meaning: the `key`-from-list_terrain_sources convention and the operational interpretation of timeout as 'returns timed_out, then poll get_terrain', which the schema alone does not convey.

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?

States a specific verb and resource: 'Have Hydrata fetch a terrain from one of its own sources, then wait for the import'. It is clearly distinct from get_terrain (polling/reading an existing import) and from presign_terrain_upload/finalize_terrain_upload (user-supplied DEM), because it emphasizes the source catalog path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete routing: use a `key` from list_terrain_sources, and when the call returns `timed_out`, keep calling get_terrain(project_id, terrain_id). It also enumerates when the tool won't proceed (bbox over the source size cap, no source data, unknown source). It stops short of explicitly contrasting with the upload flow (presign/finalize), leaving one sibling choice to inference.

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