Hydrata MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Add flood observations to a layer

add_observations

Add flood observations (marks, timed levels, gauge records, dry points) to a layer, validating each row and reporting rejected rows or stopped batches.

Instructions

Add flood observations (Flood mark, Timed level, Gauge record, Dry point) to a layer.

POSTs each observation to /projects//flood-observations//observations/ in order. The API validates every field: a row it refuses (400) is listed in rejected with its problems and the rest still land; a refusal that is not about the row (403 not an Editor, 404, 409) stops the batch and is reported in stopped, with not_sent_count. Stages are on the LAYER's vertical datum. Photos are not part of an observation: attach a link with add_observation_photo_link.

Input Schema

Name	Required	Description
`srid`	No	EPSG code for every geometry that does not carry its own `srid` (the projected CRS its eastings/northings are in, e.g. a UTM zone); omit for [lon, lat] (EPSG:4326)
`layer_id`	Yes	The flood observation layer id (create_observation_layer / list_observations)
`project_id`	Yes	The project ID
`observations`	Yes	Observations, each the API write body: subtype (flood_mark \| timed_level \| gauge_record \| dry_point), name (required: a short label, e.g. the survey mark id), geometry {type: Point, coordinates: [lon, lat]} (or native x/y with srid), value_kind (stage \| depth) + stage_m or depth_m, uncertainty_grade (H/M/L) or uncertainty_m, bound (exact \| at_least \| at_most), observed_start/observed_end (ISO 8601; naive times read in entry_timezone, by default the project's own zone), mark_type, flood_name, source, licence, notes; a flood_mark or dry_point must say which flood it is: a date window (observed_start / observed_end) or flood_name (ask the user; never guess a date); a gauge_record needs data_timeseries_id (+ gauge_zero_m). At most 200 per call
`entry_timezone`	No	IANA zone for naive observed_start/observed_end on rows that do not carry their own entry_timezone; omit to use the project's zone (derived from where the project is, reported back as entry_timezone). Give it only when the times were read elsewhere

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Oct 29, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only cover the mutation/idempotency profile; the description goes well beyond by disclosing partial-failure semantics (400 rows land in `rejected` with `problems` while the rest still succeed), fatal-batch errors (403/404/409 stop the batch and populate `stopped` with `not_sent_count`), the 200-row cap, and sequential POST ordering.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then the endpoint/failure model, then the datum caveat and the photo alternative. Every sentence carries operational information; nothing is 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?

For a batch mutation tool with a rich schema and an output schema, the description supplies the missing behavioral contract (failure classification, limits, ordering) needed to call it correctly. Nothing an agent needs is absent.

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 non-schema context such as stages being referenced to the layer's vertical datum and the must-identify-the-flood rule for flood_mark/dry_point. Most remaining parameter detail is already carried by the very rich schema descriptions.

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 (add) and resource (flood observations) and enumerates the exact subtypes accepted. It clearly distinguishes itself from add_observation_photo_link by scoping photos out of the operation.

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 clear operating context: photos must go through add_observation_photo_link, and a flood_mark/dry_point requires a date window or flood_name ('ask the user; never guess a date'). It stops short of routing the agent to update_observation or list_observations for other workflows.

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