Create Husbandry Record

Record something done TO one mob: marking, mulesing, shearing, crutching, eID tagging, weaning, pregnancy scanning, classing, weighing, dehorning or spaying. Marking day is ONE record: procedures mark, tail_dock and castrate on 412 lambs, with product lines for the vaccine and the pain relief. Creates the one task that is the record, with its typed husbandry 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 husbandry, capture_source to agent and operator from the signed-in user. head defaults to the mob's head count. date defaults to today; a future date creates the open task instead of a completed record.

procedures is a list of mark, eid_tag, tail_dock, castrate, mules, shear, crutch, wean, scan, class, weigh, dehorn, spay, other. outcomes is a small block per procedure: mark (lambs_marked, ewes_joined), scan (singles, twins, triplets, dry), shear (shearer as text, bales, wool_kg), wean (weaned, avg_kg), weigh (avg_kg, lightest_kg, heaviest_kg). A figure the procedure does not carry is refused. marking_percent is worked out when read, never stored.

products is optional: pain relief, a vaccine at marking, jetting fluid. The same line as a treatment's, and it feeds the mob's sale status exactly like one, so a product with a withholding period matters. Never invent a batch, expiry or withholding period. A husbandry record belongs to a mob; a paddock id is a 404 here.

Before calling, check listTasks with this mob'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 mob'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 mob'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.