Create Fertiliser Record

Record fertiliser spread on one paddock: urea, MAP, super, lime, gypsum or manure. One pass across a paddock is one record. Creates the one task that is the record, with its typed fertiliser child, and answers with that task exactly as GET /tasks/{id} would. The server sets the producer from the farm's owner, operation_type to fertiliser, capture_source to agent and operator from the signed-in user. area_ha defaults to the paddock's area. date defaults to today; a future date creates the open task instead of a completed record.

Fertiliser has no withholding period and never changes a paddock's status. There are no dates on the record, and getPaddock and getFarmStatus ignore it. A line's advisory_note (urea: wait three to four weeks for nitrate risk) is advice to pass on to the farmer, not a status.

Send one products entry per product, up to 10. Type the rate as the farmer said it in rate ("100 kg/ha"); it is kept verbatim and split into rate_value, rate_unit and rate_basis. A rate with a number and no unit ("100") is refused (422, "needs a unit, e.g. 100 kg/ha"): ask the farmer for the unit. analysis is nutrient percentages, e.g. { "N": 46 }; nutrients_applied (kg/ha) and each line's total_kg are worked out when read. A completed record with no product row is refused. A fertiliser record belongs to a paddock; a mob id is a 404 here.

Before calling, check listTasks with this paddock's asset_id and filter[status][]=completed for a same-date duplicate, and confirm the summary with the farmer. The MCP tool is refused until it is called again with confirm: true. If the call errors or times out, read the paddock's records back before retrying: a 502 or 504 can arrive after the write succeeded. Do not send broadcast or share_scope. Needs a grant that allows writing in the paddock's business. A 403 whose code is insufficient_access is that refusal; its detail names the business and the access that is missing. Photos. A file on disk is staged with createImageUpload, whose curl_example PUTs the bytes, and attached with image_upload_ids. Never base64-encode a local photo into a tool call. A public http(s) URL: pass image_urls. Only a tiny generated image (under about 100 KB decoded) uses image_base64s. One upload can be attached to several records until it expires. On update, image_mode defaults to append (add to the existing photos); replace swaps them all out; remove_image_ids deletes specific ones. If any image fails, the whole create or update is rolled back. The attaching call still needs confirm: true. createImageUpload and its PUT do not.