Hydrata MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Create a time series

create_time_series

Create validated time series—rain gauge, hydrograph, or tide/stage—in a project; series type and units are checked before sending.

Instructions

Create a time series (rain gauge, hydrograph, tide/stage) in a project.

POSTs /projects//time-series/ with series_type and units as top-level fields. series_type is checked against the four choices and data against the {"rowData": [{timestamp, value}, ...]} shape before any request is made — the API answers 500 (not 400) to a malformed row. Returns a compact record — id, name, series_type, units, timezone, row_count, http_status — not the echoed rows; fetch the full row with the REST API (GET /projects//time-series//) if you need to round-trip it. A rainfall polygon references its gauge by the series NAME, so create the gauges with the exact names the rainfall GeoJSON's features carry.

The units must match the series_type (see units), and a hydrograph or hyetograph must END at 0 unless hold_last_value is true. The result carries Hydrata's own summary of the series (peak, volume or depth, first and last stamp, trailing value): repeat those numbers to the user (say_to_user does) rather than computing your own.

Input Schema

Name	Required	Description	Default
`data`	Yes	The rows: {"rowData": [{"timestamp": "1998-08-17T00:00:00", "value": 1.5}, ...]}. Timestamps ISO 8601 (a trailing Z is tolerated), values numeric. Validated here before anything is sent.
`name`	Yes	Series name, kept VERBATIM — a rainfall polygon binds to its gauge by this exact name (its `data` property), so use the name the GeoJSON features carry
`units`	No	Units of the values. REQUIRED for hyetograph ('mm/hr' or 'mm/h'), hydrograph ('m3/s', 'm^3/s' or 'cumec') and stage ('m'): the engine reads those units whatever the label says, so a mismatch is refused before anything is sent. Free for generic.
`method`	No	One short phrase saying how you got these numbers (e.g. 'read off the council hydrograph PDF', 'scaled the 1% AEP peak'). Shown to the person who reviews the inputs.
`source`	No	Where the data came from, e.g. a gauge id or agency (optional)
`timezone`	No	IANA timezone of the timestamps (default 'UTC'), e.g. 'Australia/Sydney'	UTC
`project_id`	Yes	The project ID
`description`	No	Free-text description (optional)
`series_type`	No	One of hyetograph (rainfall depth/intensity — the default), hydrograph (flow, read by the Hydrographs panel and inflow boundaries), stage (water level, e.g. a tide) or generic. Sent as a top-level field.	hyetograph
`location_name`	No	Human-readable location of the gauge (optional)
`hold_last_value`	No	Set true ONLY when the last value is meant to be held after the series ends. A hydrograph or hyetograph whose last value is not 0 is refused (TRAILING_VALUE_HELD) unless this is true: end the series with a 0 row instead, unless holding is really intended.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.0Oct 30, 2026

addedInput schema / properties / method

Added value: +{
+  "default": "",
+  "description": "One short phrase saying how you got these numbers (e.g. 'read off the council hydrograph PDF', 'scaled the 1% AEP peak'). Shown to the person who reviews the inputs.",
+  "type": "string"
+}

First observedv0.2.1Oct 29, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false) it discloses that validation happens client-side before any request, that the API answers 500 rather than 400 to a malformed row, and that the response is a compact record rather than the echoed rows. It also explains the TRAILING_VALUE_HELD refusal path, which is exactly the kind of failure mode an agent needs warned about.

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 purpose and then ordered by what an agent must know (validation, return shape, naming/units constraints). Dense but every paragraph carries actionable content; the only mild redundancy is describing the returned fields when an output schema exists.

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 an 11-parameter, nested-object mutation tool with no enum coverage on series_type, the description supplies the missing choice set, the units-per-type rules, the validation timing and the error behavior. Return values are described even though an output schema exists, leaving no operational gap.

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 cross-parameter semantics the schema alone does not: series_type is checked against four choices, units must be consistent with series_type, and `name` is bound verbatim because rainfall polygons reference gauges by name. The hold_last_value/trailing-zero interaction is also spelled out.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 time series') and enumerates the concrete domain objects it covers (rain gauge, hydrograph, tide/stage), plus where it lives ('in a project'). It does not explicitly contrast with the sibling update_time_series or delete_time_series, so the create-vs-modify boundary is left to inference.

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 real usage conditions: units must match series_type, hydrograph/hyetograph must end at 0 unless hold_last_value is true, and gauge names must match the rainfall GeoJSON feature names. It also routes the agent elsewhere for round-tripping ('fetch the full row with the REST API'). It stops short of stating when to use update_time_series instead.

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