Hydrata MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Create a flood observation layer

create_observation_layer

Creates a project-level flood observation layer and waits until its map layer is ready, so real flood evidence can be added and compared with historic runs.

Instructions

Create a flood observation layer in a project and wait for its map layer.

A flood observation layer holds real flood evidence (Flood marks, Timed levels, Gauge records, Dry points) that every historic run is compared with (Compare with observations). It is project-level: it is never a scenario input. POSTs /projects//flood-observations/, then polls the layer until its GeoServer layer exists (ready), usually a few seconds; until then add_observations refuses. On timed_out, call list_observations later.

Input Schema

Name	Required	Description	Default
`title`	Yes	Layer title, e.g. 'August 1998 survey'
`project_id`	Yes	The project ID
`datum_offset_m`	No	Metres ADDED to every stage on the layer to bring it onto the terrain datum. Required for vertical_datum=local; null means 0 otherwise
`vertical_datum`	No	The datum the layer's stages are on: terrain (default, 'Same as terrain'), local ('Local datum (constant offset)', needs datum_offset_m), or the vertical datum the levels were surveyed on: an EPSG vertical CRS (e.g. 'EPSG:5703') or the datum's own name (at most 32 characters). Ask the user; never assume one from the country	terrain
`timeout_seconds`	No	How long to wait for the map layer (clamped to 200)
`poll_interval_seconds`	No	Seconds between layer polls

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.0Oct 30, 2026

changedInput schema / properties / timeout_seconds / description

Previous value: -"How long to wait for the map layer (clamped to 280)"New value: +"How long to wait for the map layer (clamped to 200)"

First observedv0.2.1Oct 29, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The description carries substantial context the annotations do not: the underlying POST endpoint, the fact that the call blocks and polls until a GeoServer layer reaches `ready` (seconds), that add_observations is refused during that window, and that `timed_out` is a non-fatal outcome handled later via list_observations. This is exactly the async/readiness detail an agent needs before invoking.

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 what the tool produces, then the domain meaning, then the operational behavior. Dense but purposeful. The `ready`/`timed_out` outcome names are compact and useful rather than padding.

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?

Output schema exists, so return values need no prose. For a blocking create with a 200-second clamp, the description covers creation, readiness polling, refusal of dependent calls, and timeout recovery — everything needed to call it correctly and interpret the wait.

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 description coverage is 100%, so the schema already explains vertical_datum, datum_offset_m, timeout_seconds and poll_interval_seconds. The description references waiting and timeouts implicitly but adds no parameter-level meaning beyond what the schema states, so 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?

States a specific verb and resource ('Create a flood observation layer in a project') and immediately defines the domain object (real flood evidence: Flood marks, Timed levels, Gauge records, Dry points) plus its distinguishing property: project-level, never a scenario input. An agent can separate this from create_scenario or create_time_series without opening a schema.

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?

The sequencing is explicit: creation must complete before add_observations will accept data, and a `timed_out` result should be followed by list_observations rather than a retry. It stops short of enumerating when an agent should NOT create a layer (e.g. reusing an existing one via list_observations), but the practical routing guidance is clear.

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