Hydrata MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Write a project input layer from GeoJSON

write_input_layer

Writes GeoJSON features as a project input layer (boundary, friction, inflow, rainfall, building, mesh_region or culvert) into Hydrata's grid, replacing the default layer of that kind.

Instructions

Write a project input layer (boundary, friction, inflow, rainfall, building, mesh_region or culvert) from GeoJSON you send in this call.

No file, no key, no upload: the features go in features. Hydrata converts them into the project's grid and puts them in the project's default layer of that kind, replacing what it held (the old layer is kept, unlinked). Unlike attach_input_layer there is nothing to poll.

Every feature must be the kind's geometry (lines for boundary, inflow and culvert; polygons for friction, rainfall, building and mesh_region); a feature of another geometry refuses the whole write and nothing changes. A culvert is one two-point line per culvert, Inlet first, then Outlet; its attributes are the culvert fields (name, shape, width_m, ... see the culvert guidance), nothing is renamed for you.

Limit: about 150 KB of GeoJSON (a few thousand vertices). A bigger layer is refused before anything is sent: ask the person to upload it in their browser with a request_input_upload link instead.

The layer is marked as written by your agent key and is UNREVIEWED until the user reviews it in their browser. INFLOWS: never invent an inflow location; take it from the study's files or give the user the ui_url to draw it.

Input Schema

Name	Required	Description
`kind`	Yes	Which input this is: boundary, friction, inflow, rainfall, building, mesh_region or culvert ('structure' is a deprecated alias of building).
`method`	No	One short phrase saying how you made these features (e.g. 'traced from the council PDF', 'digitised from the survey CSV'). Shown to the person who reviews the layer.
`features`	Yes	A GeoJSON FeatureCollection with every feature of this kind. Coordinates are read as EPSG:4326 (lon/lat) unless the collection declares a `crs` member; Hydrata converts them into the project's grid. Multi* geometries are split into single ones.
`project_id`	Yes	The project ID

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.0Oct 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: says the existing default layer is replaced but kept and unlinked, that a geometry mismatch refuses the entire write atomically, the ~150 KB pre-flight limit, that the layer is attributed to the agent key and is UNREVIEWED until browser review. These are precisely the side-effect and state details the hints (destructive=false, idempotent=false) cannot convey.

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?

The payload, the replace behavior and the size limit are front-loaded, with the safety-critical inflow warning last. Dense but a couple of clauses ('No file, no key, no upload') restate the same idea the preceding sentence already made.

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?

An output schema exists so return values need no prose. For a write tool with a nested GeoJSON payload, the description covers validation failure modes, size ceiling, coordinate assumption, review state and the escalation path — everything needed to call it correctly.

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; the description earns more by adding per-kind geometry constraints (lines for boundary/inflow/culvert, polygons for friction/rainfall/building/mesh_region) and culvert structure (one two-point line, Inlet then Outlet) that the schema's FeatureCollection description does not state. The `method` parameter is only covered in the schema, not the prose.

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?

Names a specific verb (write) and resource (project input layer) and enumerates the seven kinds it accepts. It is immediately distinguishable from siblings attach_input_layer and request_input_upload, which are named in the text.

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?

Explicitly routes away from attach_input_layer ('nothing to poll') and instructs the agent to use request_input_upload plus a browser upload when the payload exceeds ~150 KB. Also gives an exclusion for inflows ('never invent an inflow location'), which is a when-not rule.

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