Hydrata MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Get a terrain upload URL

presign_terrain_upload

Generate a presigned S3 PUT URL for uploading a GeoTIFF DEM, enabling the first step of terrain import before finalization.

Instructions

Step 1 of a terrain import: get a presigned S3 PUT URL for a GeoTIFF DEM.

Only for a client that has a shell and an agent key AND a DEM no platform source covers. A connector agent with no shell (claude.ai) uses list_terrain_sources then create_terrain_from_source instead, or asks the user to upload their own DEM in the map.

The import needs a launch-level agent key: a draft key can presign, but finalize_terrain_upload (and the multipart fallback below) answer a read or draft key 403 AGENT_LEVEL_INSUFFICIENT — check the key before moving bytes.

The agent moves the bytes itself — no tool accepts file contents. After this call, PUT the file straight to upload_url, sending the SAME Content-Type you passed here (it is part of the signature; a mismatch is a 403 SignatureDoesNotMatch before it is anything else):

curl -sS -X PUT -H "Content-Type: image/tiff" --upload-file /path/dem.tif "$UPLOAD_URL"

then call finalize_terrain_upload with the returned staging_key and process_id. Nothing exists in Hydrata until finalize; the URL expires after expires_in seconds (3600).

Platform guidance: keep the terrain extent within 5° across and 40,000 km² (200 × 200 km). The API enforces that cap on its bbox-fetch path; an uploaded GeoTIFF is only rejected above 5 GiB, but a larger DEM will not mesh or run well. The GeoTIFF must carry a CRS; the import reprojects it to the site's UTM zone and builds a hillshade. Fallback when a presigned PUT is impossible: multipart-POST the file with the same agent key to /api/v2/anuga/projects//terrain/upload/ (form field file, optional title), which creates the terrain in one step — then get_terrain.

Input Schema

Name	Required	Description	Default
`size`	No	File size in bytes (`stat -c %s <file>`). The API rejects > 5 GiB up front. Omit if unknown.
`filename`	Yes	Base name of the GeoTIFF, e.g. 'dem.tif' (a name only — never contents)
`project_id`	Yes	The project ID
`content_type`	No	MIME type the PUT will send (default 'image/tiff'). It is SIGNED into the URL, so the PUT must send exactly this Content-Type header.	image/tiff

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Oct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations are thin (readOnlyHint=false, destructiveHint=false), so the description carries real weight and delivers: nothing exists in Hydrata until finalize, the URL expires after 3600s, the Content-Type is signed and a mismatch yields 403 SignatureDoesNotMatch, and draft keys get 403 AGENT_LEVEL_INSUFFICIENT on finalize. It also discloses size cap (5 GiB) and CRS/reprojection behavior.

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-loads purpose and the routing decision, then sequences prerequisites, the curl example, and the fallback — a logical flow. It is long, and the platform extent guidance (5°/40,000 km²) and multipart fallback run past the immediate call, but each remains actionable context rather than filler.

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 multi-step upload handshake with an output schema already covering return values, the description supplies everything an agent needs to call correctly: prerequisites, exact PUT semantics, the follow-up call with staging_key and process_id, and the escalation path when the key is insufficient.

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 baseline is 3, but the description adds genuine meaning beyond the schema — that content_type is SIGNED into the URL and must be echoed verbatim on the PUT, and that size must be a byte count with a 5 GiB rejection threshold. It does not add much on project_id or filename that the schema lacks.

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+resource ('get a presigned S3 PUT URL for a GeoTIFF DEM') and situates it as step 1 of a multi-step import that continues in finalize_terrain_upload. It explicitly names the sibling alternatives (list_terrain_sources, create_terrain_from_source) so an agent can distinguish it without opening sibling schemas.

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 an explicit when-to-use ('a client that has a shell and an agent key AND a DEM no platform source covers') and when-not ('a connector agent with no shell (claude.ai) uses list_terrain_sources then create_terrain_from_source instead'). It also names a fallback path (multipart POST) for cases where presigned PUT is impossible, and states the key-level prerequisite.

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