eudr

Add a farm, with its boundary if known

eudr_create_farm

Add a farm to this organisation's record. A name is enough; give the crop, country and a pin (lat, lon) when known. Give its boundary as boundary (a GeoJSON Polygon or MultiPolygon, longitude first), or as fields: several field outlines (for example Fields of The World parcels) that are joined into one farm by closing the bunds and tracks between neighbours (join_m, default 3 m each way), fields farther apart kept as separate pieces. With a boundary, what follows runs at once: the country from where the land lies when none is given, the forest record warmed, and the land check when the crop is one the EU regulation covers. With only a pin, the mapped fields around it are looked up as suggestions for a person to accept. This writes to the organisation's record.

Input Schema

Name	Required	Description
`lat`	No	A pin on the farm, in WGS84 degrees. Use it when no boundary is known.
`lon`	No	The pin's longitude, WGS84 degrees. GeoJSON order is longitude first; this field is not.
`crop`	No	What grows there, in plain words (`cocoa`, `coffee`, `oil palm`). It decides whether the EU deforestation rules apply at all.
`name`	Yes	What the farm is called, as the buyer and the farmer would say it.
`fields`	No	GeoJSON Polygons to join into one farm.
`join_m`	No	How far apart two field outlines may be and still be treated as one farm, in metres each way. Default 3, which closes the bunds and tracks between neighbouring parcels.
`country`	No	ISO 3166-1 alpha-2.
`boundary`	No	GeoJSON Polygon or MultiPolygon.

Output Schema

Name	Required	Description	Default
`then`	No
`farm_id`	Yes
`boundary`	No
`farm_url`	Yes
`next_action`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 15, 2026

addedInput schema / properties / crop / description

Added value: +"What grows there, in plain words (`cocoa`, `coffee`, `oil palm`). It decides whether the EU deforestation rules apply at all."

addedInput schema / properties / join_m / description

Added value: +"How far apart two field outlines may be and still be treated as one farm, in metres each way. Default 3, which closes the bunds and tracks between neighbouring parcels."

addedInput schema / properties / lat / description

Added value: +"A pin on the farm, in WGS84 degrees. Use it when no boundary is known."

addedInput schema / properties / lon / description

Added value: +"The pin's longitude, WGS84 degrees. GeoJSON order is longitude first; this field is not."

addedInput schema / properties / name / description

Added value: +"What the farm is called, as the buyer and the farmer would say it."

AddedSep 29, 2026

TDQS

A4/5.0

Behavior5/5

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

Beyond the annotations (write, open-world, non-idempotent, non-destructive), the description discloses the actual side-effect chain: country auto-derived from the land, forest record warmed, and the EUDR land check triggered when the crop is covered; with only a pin, mapped fields are merely suggested for human acceptance. That is materially more than the annotations 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?

Front-loaded with the core action, then dense but purposeful detail on geometry input and cascade behavior; almost every sentence earns its place. The one long mid-paragraph sentence about what 'runs at once' is somewhat run-on and forces a re-read.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 explanation, and the description covers required vs optional inputs and cascading effects well. Gaps remain around permissions/auth and what happens on a duplicate create (idempotentHint is false but duplicates go unmentioned).

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 would be 3, but the description adds semantics the schema does not: how `fields` are joined by closing bunds and tracks, what `join_m` achieves in practice, and that `crop` decides whether the EUDR rules apply. It adds genuine meaning on top of the field-level descriptions.

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 ('Add a farm to this organisation's record') plus the conditional scope 'with its boundary if known', so the agent knows this is a create operation that may also ingest geometry. It never names the obvious sibling (eudr_set_farm_boundary) to draw the line between creating-with-boundary and attaching a boundary later, so sibling differentiation is only implied.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives real context for input choice: 'a name is enough', give a pin 'when no boundary is known', and boundary or fields when the outline exists. However it offers no tool-level guidance — nothing tells the agent when to call this versus eudr_set_farm_boundary or eudr_list_farms, and no prerequisites or exclusions are stated.

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

All eudr tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.