@sebamomann/plants-mcp 2.8.2 → 2.13.0

package/CHANGELOG.md

@@ -3,6 +3,92 @@
 Notable changes to `@sebamomann/plants-mcp`. Versioning is semver against the **tool surface** —
 see the table in `AGENTS.md` for what counts as major, minor, and patch.
 
+## 2.13.0 — 2026-09-30
+
+**New tool: `merge_soils`.** Tool count 78 → 79 (28 read, 33 write, 18 admin). A **minor** bump —
+one new write tool, nothing renamed or removed:
+
+- `POST /api/v1/soils/merge` with `sourceId`/`targetId` (both required) moves every plant and
+  potting-event record from `sourceId` onto `targetId`, then deletes `sourceId` — for duplicate
+  soil mixes (idea 89; prod had 23 soils for 96 plants, including a literal duplicate pair
+  differing only by a space).
+- Unlike deleting a soil directly, it never refuses for living plants still using the source —
+  moving them onto the target first is the point, so nothing is left dangling. `sourceId`'s own
+  mix recipe (its components/parts) is dropped; `targetId` keeps its own unchanged.
+- Irreversible, like `admin_merge_plant_types` — there is no unmerge tool for soils. Shares its
+  ownership-checked, transactional core (`app/_lib/soils/mergeSoils.ts`) with the app's own
+  "Zusammenführen mit …" action on the soil detail page, so an MCP-triggered merge and a
+  UI-triggered one behave identically.
+
+## 2.12.0 — 2026-09-30
+
+**`record_fertilization` now also logs the watering a feeding is given with.** Tool count
+unchanged (78). A **minor** bump — one new response field, nothing renamed or removed, but a
+behaviour change worth reading before the next call:
+
+- Fertilizer goes into the can, so the app treats a fed plant as a watered plant. Every fertilized
+  plant now also gets that day's watering-type event — routed exactly like `record_watering` (a
+  `WateringEvent` for a scheduled plant, a `RefillEvent` for reservoir, a `HydroEvent` top-up for
+  hydro) — unless one already exists for that day. The response gains `alsoWatered: number[]`
+  listing the plants that got one.
+- A plant skipped because it was already fertilized that day is left entirely alone (no watering
+  either), as before.
+- **Callers that used to pair `record_fertilization` with `record_watering` for the same plants
+  should drop the second call** — it would now be skipped as a same-day duplicate anyway, but the
+  extra round trip is wasted.
+- This matches the app: its fertilize card's primary now reads "Düngen + gießen" and writes both,
+  and the old "also water" secondary is gone. Solid fertilizers (sticks, granules) are not modelled
+  yet — see `docs/feature-ideas.md` #79 — so the rule is unconditional for now.
+
+## 2.11.0 — 2026-09-29
+
+**`dismiss_care_recommendation` gains a new dismissible type, `possibleDecline`.** Tool count
+unchanged (78). A **minor** bump — one new accepted enum value, nothing renamed or removed:
+
+- Idea 72's deterministic "this plant might be drifting" signal, surfaced by
+  `list_care_recommendations` like any other recommendation: a plant never watered, a watering
+  rhythm stretching against its own past rhythm, repeated snoozes/"still moist" skips (idea 70),
+  a fertilization inside its post-repotting rest window, or watered markedly less often than other
+  plants of the same type in the collection. No AI runs to produce it — the owner's hard constraint
+  was that nothing may scan the collection to save on AI cost, and this reads only rows already
+  stored.
+- `values.kind` names which of the above fired; `values.otherSignalCount` says how many more also
+  applied for that plant. Like `propagationCheckDue`, its dismissal is temporary (about a month),
+  not permanent — a still-true situation is meant to surface again, not hide forever.
+- The in-app card's "genauer ansehen" opens the existing guided diagnosis pre-filled with the
+  signal; that flow itself has no MCP surface of its own yet (`list_diagnoses` is read-only), so
+  there is nothing further for this package to expose for it.
+
+## 2.10.0 — 2026-09-29
+
+**`set_plant_status` gains `deathNote`, and `deathCause` now also applies to `LOST`.** Tool count
+unchanged (78). A **minor** bump — one new optional argument, one existing argument's scope
+widened, nothing renamed or removed:
+
+- `deathNote` (optional, max 300 characters) is a free-text detail alongside `deathCause`'s
+  constrained pick — idea 68's "picks, not free text as the primary, plus an optional sentence."
+- `deathCause` previously applied only when `status` is `DEAD`; it (and the new `deathNote`) now
+  apply to `LOST` too. A plant marked `LOST` is gone the same way a `DEAD` one is — the app's
+  finding was that all 7 currently-lost plants (6 `DEAD`, 1 `LOST`) had a null `deathCause`, and
+  the `LOST` one had no path to set it at all. `deadDeclaredAt` stays `DEAD`-only: "declared dead
+  on" has no equivalent for a plant that was lost or discarded.
+- Both fields are still entirely optional on every call — capturing a cause never gates the status
+  change itself (idea 68: "the cause must be skippable, since a gate would be worse than a null").
+
+## 2.9.0 — 2026-09-29
+
+**`record_repotting` gains a same-day duplicate guard.** Tool count unchanged (78). A **minor**
+bump — one new optional argument, nothing renamed or removed:
+
+- A plant that already has a potting event on the resolved `pottedAt` day now gets a `409` instead
+  of a second, identical event silently created (idea 59 — production data had turned up two
+  potting events for the same plant, 34 seconds apart). Pass `confirmDuplicate: true` to log a
+  genuine second repotting on the same day anyway.
+- `record_watering`/`record_fertilization` and their app-side single-plant "mark now" actions are
+  unaffected by this bump — they already skip (rather than reject) a same-day repeat, and that
+  behavior is unchanged. The app's own single-plant quick-log buttons gained the same silent skip
+  in this release for consistency, but that is app-internal and not part of this package's surface.
+
 ## 2.8.2 — 2026-09-29
 
 **Correction to 2.8.1.** Tool count unchanged (78). A **patch** bump — nothing renamed or removed:

package/README.md

@@ -60,7 +60,7 @@ needs a running Sprig instance and an API key from it. Start at the
 
 ## What an assistant can do
 
-**78 tools** over your collection: 28 that read it, 32 that write to it. **18 admin tools** are also
+**79 tools** over your collection: 28 that read it, 33 that write to it. **18 admin tools** are also
 available — but only to a key created by an admin — for finding and understanding duplicates in the
 shared global plant type catalog, restructuring its genus/species/cultivar tree, reading, directly
 editing, merging, and reviewing proposals and duplicate candidates in that catalog, and (7 read-only,
@@ -75,7 +75,8 @@ hydro events, snoozing a due date, health notes, dismissing care recommendations
 identity/care schedule/settings/lifecycle status, adding a plant (identified or not), propagating
 one, merging plants together and reversing that merge, deleting a watering or fertilization event,
 managing the wishlist (add, note, remove), watching or unwatching a plant type, marking notifications
-read, creating a location/soil/fertilizer/pot, and contributing a new species to the shared catalog.
+read, creating a location/soil/fertilizer/pot, merging a duplicate soil into another, and
+contributing a new species to the shared catalog.
 
 **Plant identity moved to a shared, community-maintained catalog in 2.0.0** — see **Breaking changes
 in 2.0.0** below before upgrading a client that stored a `plantTypeId`.
@@ -111,7 +112,7 @@ healthy server, not a hang — press Ctrl-C.
 The scope lives on the API key, is enforced by the app, and cannot be widened from this side.
 
 - **`read`** — on every key. Gates all 28 read tools.
-- **`write`** — opt-in when you create the key. Gates the 32 write tools.
+- **`write`** — opt-in when you create the key. Gates the 33 write tools.
 - **`admin`** — only offered when the key's creator is themselves an admin, and only while they
   still are one (the app re-checks this on every admin-tool call, not just at key creation). Gates
   the 18 admin catalog tools — 7 read-only, 11 that write — see **Admin tools** below. `admin` alone
@@ -139,7 +140,10 @@ Not oversights — deliberate limits:
   alternative, so those two are destructive and **cannot be undone**. `remove_from_wishlist` and
   `unwatch_type` are two more deletes, but not in the same sense — a wish or a watch is a personal
   to-do item / subscription with no history to lose, trivially re-added with `add_to_wishlist` /
-  `watch_type` if removed by mistake.
+  `watch_type` if removed by mistake. `merge_soils` also ends with a deleted catalog entry, but as
+  a side effect of consolidating a duplicate, not a standalone delete: everything the source soil
+  referenced moves to the target first, so no plant or potting-event history is lost — only the
+  now-redundant soil row and its own mix recipe.
 - **No sales or trades.** Those records name a second person who never consented to your API key.
 - **No share-link creation.** Minting a public URL for your collection is a decision for the UI.
 - **No cross-user access.** Ownership comes from the key; a tool has no way to even express
@@ -201,12 +205,22 @@ overrides the Apr–Sep default), `locationId`.
 | `get_care_calendar` | `GET /api/v1/care/calendar` | `days` (1–60, default 14) | Day-by-day projection plus an overdue group |
 | `list_care_recommendations` | `GET /api/v1/care/recommendations` | none | Detected problems: cycle mismatch, chronic lateness, missed seasonal fertilizing, fertilizer pause after repotting, repotting overdue, stale photos |
 
-Four things to know when reading schedule results:
+Five things to know when reading schedule results:
 
 - **Days, not timestamps.** `nextDue` and `date` are local `YYYY-MM-DD` strings — a UTC timestamp
   would render as the wrong day east of Greenwich.
 - **`neverLogged` is its own bucket.** A plant with a cycle but no event yet has no anchor, so no
   due date can be computed. Those are returned separately rather than reported as overdue.
+- **`reservoirChecks` is where reservoir and hydro plants show up.** They have no watering cycle, so
+  they never appear in `tasks`, `days[]` or `neverLogged` at all. Instead, `list_due_care` and
+  `get_care_calendar` each carry a `reservoirChecks` array of `{ plantId, nextCheckAt,
+  daysUntilCheck, confidence }` — a *predicted* next check, the median gap between that plant's own
+  last few refills (reservoir) or hydro entries, not a schedule the user configured. `nextCheckAt` is
+  a `YYYY-MM-DD` day like `nextDue`; `daysUntilCheck` is negative once it has passed; `confidence` is
+  `"rough"` below three observed gaps and `"established"` from there on. The array ignores
+  `windowDays`/`days` — every plant with a prediction is always in it — and a plant with fewer than
+  two entries on distinct days has no entry at all. `list_overdue_care` carries the same array
+  narrowed to the checks whose day is today or already past (`daysUntilCheck <= 0`).
 - **Fertilizing follows the app's calendar, including where it's grouped.** A fertilizing entry
   carries `wateringAlignedOn` (a `YYYY-MM-DD` day, `null` when absent) — set when the app's
   water-align rule has attached that feeding to a watering: unconditionally when it's due before
@@ -357,7 +371,7 @@ description starts with `WRITE:` so a model cannot mistake one for a read.
 |---|---|---|
 | `record_watering` | `POST /api/v1/care/watering` | `plantIds` **(required,** 1–200**)**, `wateredAt` (`YYYY-MM-DD`, defaults to now, no future dates) |
 | `record_fertilization` | `POST /api/v1/care/fertilization` | `plantIds` **(required,** 1–200**)**, `fertilizerId`, `fertilizerPercent` (0–1000), `fertilizedAt` |
-| `record_repotting` | `POST /api/v1/plants/:id/repotting` | `plantId`, `potId` **(both required)**, plus `potSizeId`, `soilId`, `pottedAt`, `hasDrainage`, `hasClimbingAid`, `notes` |
+| `record_repotting` | `POST /api/v1/plants/:id/repotting` | `plantId`, `potId` **(both required)**, plus `potSizeId`, `soilId`, `pottedAt`, `hasDrainage`, `hasClimbingAid`, `notes`, `confirmDuplicate` |
 | `record_refill` | `POST /api/v1/plants/:id/refill` | `plantId` **(required)**, plus `fertilizerId`, `fertilizerPercent`, `refilledAt` |
 | `record_hydro_event` | `POST /api/v1/plants/:id/hydro` | `plantId` **(required)**, plus `kind` (`topup`\|`change`), `waterLevel` (0–100), `fertilizerId`, `fertilizerPercent`, `recordedAt`, `notes` |
 | `snooze_care` | `POST /api/v1/care/snooze` | `plantId`, `careType` (`water`\|`fert`), `originalDueAt` **(all required)**, exactly one of `durationDays` (1, 3, 7, or 14) or `snoozedUntil` (`YYYY-MM-DD`), `note` |
@@ -369,11 +383,17 @@ fertilization logged.
 `record_fertilization` defaults `fertilizerId` and `fertilizerPercent` to **each plant's own
 settings** when omitted, so a bulk call across differently-configured plants still does the right
 thing per plant. `record_refill` and `record_hydro_event` default the same two fields the same way.
+Since 2.12.0 it also mirrors the app's rule that fertilizer goes into the can: every fertilized
+plant gets that day's watering logged as well (routed like `record_watering` — a refill for
+reservoir plants, a top-up for hydro) unless one already exists, and the response lists those
+plants under `alsoWatered`. Do not follow it with `record_watering` for the same plants.
 
 `record_repotting` re-derives the plant's current soil from its latest potting event, and syncs
 watering/fertilizing mode when the new pot's self-watering flag changes it — the same the app's own
 repotting form does. `pottedAt` defaults to today, or to the plant's `acquiredAt` for its very
-first-ever potting event.
+first-ever potting event. If the plant already has a potting event on that day, the call fails with
+a 409 instead of creating a second one — pass `confirmDuplicate: true` to log a genuine second
+repotting on the same day anyway.
 
 `record_refill` is the dedicated tool for a reservoir plant's fertilizer/percent — `record_watering`
 already routes a plain watering to a refill for these plants, but without those fields. Like the
@@ -445,7 +465,7 @@ don't exist yet, `propagate_plant` creates them *and* sets the link in one call.
 | `propagate_plant` | `POST /api/v1/plants/:id/propagations` | `plantId` **(required)**, `count` (1–10, default 1) |
 | `merge_plants` | `POST /api/v1/plants/merge` | `sourcePlantIds` **(required,** 1–200**)**, plus **exactly one of** `survivorPlantId` or `createNewFrom` |
 | `unmerge_plant` | `POST /api/v1/plants/:id/unmerge` | `plantId` **(required)** |
-| `set_plant_status` | `PATCH /api/v1/plants/:id/status` | `plantId`, `status` (`LIVING`\|`DEAD`\|`LOST`) **(both required)**, plus `deadDeclaredAt`/`deathCause` (only apply when `status` is `DEAD`) |
+| `set_plant_status` | `PATCH /api/v1/plants/:id/status` | `plantId`, `status` (`LIVING`\|`DEAD`\|`LOST`) **(both required)**, plus `deadDeclaredAt` (only applies when `status` is `DEAD`) and `deathCause`/`deathNote` (only apply when `status` is `DEAD` or `LOST`) |
 | `set_plant_reference` | `PATCH /api/v1/plants/:id/reference` | `plantId`, `reference` (boolean) **(both required)** |
 | `establish_propagation` | `PATCH /api/v1/plants/:id/establish` | `plantId` **(required)** |
 
@@ -474,8 +494,10 @@ longer want it, deleting that plant is a UI action.
 do**), and `MERGED`/`SPLIT`/`EXTERNAL` each have their own dedicated tool
 (`merge_plants`/`unmerge_plant`, `set_plant_reference`) that keeps their companion state consistent —
 setting `status` alone to one of those would corrupt it. `deadDeclaredAt` defaults to the plant's
-existing value, then today; moving a plant away from `DEAD` clears both `deadDeclaredAt` and
-`deathCause`.
+existing value, then today, and only applies to `DEAD`. `deathCause` (a constrained pick) and
+`deathNote` (an optional free-text detail, max 300 characters) apply to `DEAD` and `LOST` alike —
+a plant marked `LOST` is gone the same way a `DEAD` one is. Moving a plant to `LIVING` clears all
+three.
 
 `set_plant_reference` flips a plant between `LIVING` (yours) and `EXTERNAL` (a reference plant —
 somebody else's, kept only as a lineage anchor): `reference: true` requires the plant to currently be
@@ -512,9 +534,9 @@ Pass all three **exactly as returned by `list_care_recommendations`**. The `fing
 that specific occurrence, so dismissing one never suppresses a later, different recurrence.
 
 Dismissible `type` values: `wateringOftenLate`, `fertilizingOftenLate`, `noFertilizerThisSeason`,
-`recentlyRepottedAvoidFertilizer`, `noRecentPhoto`, `propagationCheckDue`. `wateringCycleMismatch` is
-**not** dismissible — it is a configuration contradiction, fixed by editing the plant rather than
-hidden.
+`recentlyRepottedAvoidFertilizer`, `noRecentPhoto`, `propagationCheckDue`, `possibleDecline`.
+`wateringCycleMismatch` is **not** dismissible — it is a configuration contradiction, fixed by
+editing the plant rather than hidden.
 
 `propagationCheckDue` ("is it still a cutting?") fires for a plant that has been `PROPAGATING` for a
 while and asks whether it has rooted. Dismissing it only hides it for a few weeks, not permanently —
@@ -522,6 +544,18 @@ it re-fires periodically rather than letting a stale `PROPAGATING` row silently
 success rate in `collection_stats`. `establish_propagation` (see **Plant lifecycle** above) is how an
 assistant acts on it — promoting the plant is the actual fix, not just dismissing the prompt.
 
+`possibleDecline` is a deterministic, zero-cost "this plant might be drifting" signal — never
+watered, a watering rhythm stretching against the plant's own past rhythm, repeated snoozes/"still
+moist" skips, a fertilization inside its post-repotting rest window, or watered markedly less often
+than other plants of the same type in the collection. No AI runs to produce it; `values.kind` names
+which of those it is, and `values.otherSignalCount` says how many more also apply. Like
+`propagationCheckDue`, dismissing it is temporary (about a month), since a still-true situation
+should surface again rather than hide forever.
+
+`noRecentPhoto` and `repotDue` dismiss the same way — temporarily, not forever — since their
+fingerprints are anchored to the last photo/potting event and nothing short of a new one moves them:
+`noRecentPhoto` re-fires after about a month, `repotDue` after about a season.
+
 ### Wishlist
 
 | Tool | Endpoint | Arguments |
@@ -561,6 +595,7 @@ mirror (opening the page already marks everything read).
 |---|---|---|
 | `create_location` | `POST /api/v1/locations` | `name` **(required)**, `parentId` (an owned location, to nest under) |
 | `create_soil` | `POST /api/v1/soils` | `name` **(required)**, `notes`, `items` (`{ componentName, parts }[]`, each component upserted by name) |
+| `merge_soils` | `POST /api/v1/soils/merge` | `sourceId` **(required)**, `targetId` **(required)** |
 | `create_fertilizer` | `POST /api/v1/fertilizers` | `name` **(required)**, `npk`, `baseDosePerLiterMl` (0–100) |
 | `create_pot` | `POST /api/v1/pots` | `name` **(required)**, `material`, `isSelfWatering`, `notes`, `links` (`{ url, label? }[]`) |
 | `create_plant_type` | `POST /api/v1/plant-types` | at least one of `genus`/`commonName`; `species`, `cultivar`, `values` (`sunRequirement`/`waterRequirement` required within it), `note`, `confirmDespiteDuplicates` |
@@ -570,6 +605,12 @@ inline" picker on the plant form — same validation, same duplicate-name handli
 used by one of your own rows in that catalog is rejected). Pot *sizes* have no create tool yet; add
 one from the app after creating the pot.
 
+`merge_soils` moves every plant and potting-event record from `sourceId` onto `targetId`, then
+deletes `sourceId` — for duplicate soil mixes (e.g. names differing only by a stray space). Unlike
+deleting a soil directly, it never refuses for living plants still using it — moving them onto the
+target is the point. `sourceId`'s own mix recipe is dropped; `targetId` keeps its own. There is no
+unmerge — it is the one irreversible write tool in this catalog section.
+
 `create_plant_type` adds a species/cultivar the shared catalog is missing — the same capability as
 the plant-type picker's "Neue Art anlegen" dialog, always landing `UNVERIFIED`. Unlike that dialog
 (which warns about likely duplicates client-side before you even submit), this checks

package/dist/index.js

@@ -99,7 +99,7 @@ server.tool("list_due_care", "What needs water or fertilizer now: overdue work p
         .describe("Include already-overdue work (default true)."),
 }, async (args) => apiGet("/api/v1/care/due", { ...args, includeOverdue: args.includeOverdue?.toString() }));
 server.tool("list_overdue_care", "Only work whose due date has already passed, most overdue first, with how many days each is late. Use for 'what have I fallen behind on?'. A feeding waiting on a future watering (`wateringAlignedOn` set — see `get_care_calendar`) is not listed here even when its own `nextDue` has passed: it's due on the watering's day, not neglected.", careArgs, async (args) => apiGet("/api/v1/care/overdue", args));
-server.tool("get_care_calendar", "Day-by-day care schedule over a date range, plus an overdue group. Each plant appears on its next due day only — this projects the current schedule rather than simulating future waterings. Fertilizing follows the app calendar's water-align rule: a feeding due before a plant's next watering is bucketed there unconditionally, and one due shortly after may ride along with it (within a third of the watering interval, capped at a quarter of the feeding's own cycle) — either way the fertilizing entry's `wateringAlignedOn` (YYYY-MM-DD) names that day and the bucket it's placed in follows it, while `nextDue` keeps the feeding's own, unchanged due date. A plant with no watering schedule (reservoir/hydro) has no watering to attach a feeding to, so its `wateringAlignedOn` is always null and the feeding stays on its own due date.", {
+server.tool("get_care_calendar", "Day-by-day care schedule over a date range, plus an overdue group. Each plant's watering appears on its next due day only — this projects the current schedule rather than simulating future waterings. Fertilizing follows the app calendar's water-align rule: a feeding due before a plant's next watering is bucketed there unconditionally; one due later is bucketed with whichever of the plant's watering days (projected forward from its rhythm) is nearest — pulled onto the earlier one within a third of the watering interval (capped at a quarter of the feeding's own cycle), otherwise held for the later one (capped at half the feeding's own cycle) — so a fertilizer-only day never appears when a watering is close. Either way the fertilizing entry's `wateringAlignedOn` (YYYY-MM-DD) names that day and the bucket it's placed in follows it, while `nextDue` keeps the feeding's own, unchanged due date. A plant with no watering schedule (reservoir/hydro) has no watering to attach a feeding to, so its `wateringAlignedOn` is always null and the feeding stays on its own due date.", {
     ...careArgs,
     days: z.number().int().min(1).max(60).optional().describe("Number of days to project (default 14, max 60)."),
 }, async (args) => apiGet("/api/v1/care/calendar", args));
@@ -139,7 +139,7 @@ server.tool("record_watering", "WRITE: log a watering for one or more plants. Re
     plantIds: z.array(z.number().int().positive()).min(1).max(200).describe("Plant ids to water."),
     wateredAt: optionalPlantDate(""),
 }, async ({ plantIds, wateredAt }) => apiSend("POST", "/api/v1/care/watering", { plantIds, wateredAt }));
-server.tool("record_fertilization", "WRITE: log a fertilization for one or more plants. fertilizerId and fertilizerPercent default to each plant's own settings when omitted. Plants already fertilized that day are skipped. Requires a write-scoped API key.", {
+server.tool("record_fertilization", "WRITE: log a fertilization for one or more plants. Fertilizer goes into the watering can, so each fertilized plant also gets that day's watering logged (a refill for reservoir plants, a top-up for hydro) unless one already exists — reported as alsoWatered; do not call record_watering for the same plants afterwards. fertilizerId and fertilizerPercent default to each plant's own settings when omitted. Plants already fertilized that day are skipped entirely. Requires a write-scoped API key.", {
     plantIds: z.array(z.number().int().positive()).min(1).max(200).describe("Plant ids to fertilize."),
     fertilizerId: z.number().int().positive().optional().describe("Override fertilizer; defaults to each plant's own."),
     fertilizerPercent: z
@@ -151,7 +151,7 @@ server.tool("record_fertilization", "WRITE: log a fertilization for one or more
         .describe("Strength as a percentage of the base dose; defaults to each plant's own."),
     fertilizedAt: optionalPlantDate(""),
 }, async (args) => apiSend("POST", "/api/v1/care/fertilization", { ...args }));
-server.tool("record_repotting", "WRITE: log a repotting — new pot, and optionally a new soil mix and/or pot size. Re-derives the plant's current soil from its latest potting event, and syncs watering/fertilizing mode when the new pot's self-watering flag changes it (the same way the app's own repotting form does). pottedAt defaults to today, or to the plant's acquiredAt date if this is its very first-ever potting event. Requires a write-scoped API key.", {
+server.tool("record_repotting", "WRITE: log a repotting — new pot, and optionally a new soil mix and/or pot size. Re-derives the plant's current soil from its latest potting event, and syncs watering/fertilizing mode when the new pot's self-watering flag changes it (the same way the app's own repotting form does). pottedAt defaults to today, or to the plant's acquiredAt date if this is its very first-ever potting event. Same-day guard: if the plant already has a potting event on the resolved pottedAt day, this fails with a 409 instead of creating a second one — pass confirmDuplicate: true to log a genuine second repotting on the same day anyway. Requires a write-scoped API key.", {
     plantId: z.number().int().positive().describe("Plant id."),
     potId: z.number().int().positive().describe("Pot id, from list_pots (the caller's own pots, plus shared defaults)."),
     potSizeId: z.number().int().positive().optional().describe("One of the pot's own recorded sizes, from that pot's row in list_pots."),
@@ -160,6 +160,10 @@ server.tool("record_repotting", "WRITE: log a repotting — new pot, and optiona
     hasDrainage: z.boolean().optional().describe("Whether the pot has a drainage hole."),
     hasClimbingAid: z.boolean().optional().describe("Whether a climbing aid (moss pole, trellis) was added."),
     notes: z.string().max(2000).optional().describe("Free-text notes about this repotting."),
+    confirmDuplicate: z
+        .boolean()
+        .optional()
+        .describe("Pass true to log a second potting event on a day that already has one — otherwise that call fails with a 409."),
 }, async ({ plantId, ...body }) => apiSend("POST", `/api/v1/plants/${plantId}/repotting`, body));
 server.tool("record_refill", "WRITE: log a reservoir refill for a reservoir-mode plant — the dedicated tool for logging the fertilizer/percent that go with it (record_watering already routes a plain watering to a refill for these plants, but without those fields). fertilizerId/fertilizerPercent default to the plant's own settings when omitted. When the plant fertilizes with every watering, also logs a matching fertilization. Requires a write-scoped API key.", {
     plantId: z.number().int().positive().describe("Plant id."),
@@ -239,6 +243,7 @@ server.tool("dismiss_care_recommendation", "WRITE: hide one care recommendation,
         "recentlyRepottedAvoidFertilizer",
         "noRecentPhoto",
         "propagationCheckDue",
+        "possibleDecline",
     ])
         .describe("Recommendation type, from list_care_recommendations."),
     fingerprint: z.string().min(1).describe("Occurrence fingerprint, from list_care_recommendations."),
@@ -277,14 +282,15 @@ server.tool("merge_plants", "WRITE: merge several living plants into one — for
 server.tool("unmerge_plant", "WRITE: reverse a merge for one plant — takes a MERGED plant back to LIVING and clears its link to the survivor. Undoes one source at a time, so call it per plant to fully reverse a multi-plant merge. The survivor is left in place; delete it in the UI if it was created by the merge and is no longer wanted. Requires a write-scoped API key.", {
     plantId: z.number().int().positive().describe("The MERGED plant to restore."),
 }, async ({ plantId }) => apiSend("POST", `/api/v1/plants/${plantId}/unmerge`));
-server.tool("set_plant_status", "WRITE: set a plant's lifecycle status to LIVING, DEAD, or LOST. This is deliberately narrower than the full status range the app's edit form offers: GIFTED/SOLD/TRADED need a recipient and are out of scope for an API key (see docs), and MERGED/SPLIT/EXTERNAL each have their own dedicated tools (merge_plants/unmerge_plant, set_plant_reference) that keep their companion state consistent — setting status alone to one of those would corrupt it. deadDeclaredAt/deathCause only apply when status is DEAD (deadDeclaredAt defaults to the plant's existing value, then today); moving away from DEAD clears both. Requires a write-scoped API key.", {
+server.tool("set_plant_status", "WRITE: set a plant's lifecycle status to LIVING, DEAD, or LOST. This is deliberately narrower than the full status range the app's edit form offers: GIFTED/SOLD/TRADED need a recipient and are out of scope for an API key (see docs), and MERGED/SPLIT/EXTERNAL each have their own dedicated tools (merge_plants/unmerge_plant, set_plant_reference) that keep their companion state consistent — setting status alone to one of those would corrupt it. deadDeclaredAt only applies when status is DEAD (defaults to the plant's existing value, then today). deathCause/deathNote apply to DEAD and LOST alike — a plant marked LOST is gone the same way a DEAD one is, and both feed the same after-the-fact retrospective the app builds from watering/repotting/photo history. Moving to LIVING clears deadDeclaredAt, deathCause, and deathNote. Requires a write-scoped API key.", {
     plantId: z.number().int().positive().describe("Plant id."),
     status: z.enum(["LIVING", "DEAD", "LOST"]).describe("New status."),
     deadDeclaredAt: optionalPlantDate("Only applies when status is DEAD."),
     deathCause: z
         .enum(["overwatering", "underwatering", "pests", "disease", "rootRot", "light", "cold", "transplantShock", "oldAge", "unknown", "other"])
         .optional()
-        .describe("Only applies when status is DEAD."),
+        .describe("Only applies when status is DEAD or LOST. A constrained pick, not free text — pass 'unknown' rather than omitting it when the cause genuinely isn't known but you want that on record."),
+    deathNote: z.string().max(300).optional().describe("Only applies when status is DEAD or LOST. Optional free-text detail alongside deathCause, e.g. 'moved outside for summer, forgot to bring in before the first frost'."),
 }, async ({ plantId, ...body }) => apiSend("PATCH", `/api/v1/plants/${plantId}/status`, body));
 server.tool("set_plant_reference", "WRITE: flip a plant between LIVING (the caller's own) and EXTERNAL (a reference plant — somebody else's, kept only as a lineage anchor). reference: true requires the plant to currently be LIVING; false requires it to currently be EXTERNAL. Reversible either direction; nothing on the plant is lost (photos, notes, care history, lineage all stay). Marking a plant as a reference also removes it from any vacation plan, since a reference plant is never cared for. create_plant's reference flag covers making a *new* reference plant; this is for converting one already in the collection. Requires a write-scoped API key.", {
     plantId: z.number().int().positive().describe("Plant id."),
@@ -392,6 +398,10 @@ server.tool("create_soil", "WRITE: create a soil mix, optionally with components
         .optional()
         .describe("Mix components as whole-number parts, e.g. [{ componentName: 'Kokoserde', parts: 3 }, { componentName: 'Perlite', parts: 1 }]. Omit for a soil with no recorded mix."),
 }, async ({ name, notes, items }) => apiSend("POST", "/api/v1/soils", { name, notes, items }));
+server.tool("merge_soils", "WRITE: merge one soil into another — for duplicate soil mixes (e.g. names differing only by a stray space). Every plant and potting-event record on sourceId moves to targetId, then sourceId is deleted. Unlike deleting a soil directly, this never refuses for living plants still using it — moving them is the point. sourceId's own mix recipe (components/parts) is dropped; targetId keeps its own. Irreversible — there is no unmerge. Requires a write-scoped API key.", {
+    sourceId: z.number().int().positive().describe("The soil to merge away and delete. From list_soils."),
+    targetId: z.number().int().positive().describe("The soil that survives and absorbs sourceId's plants and potting events. From list_soils."),
+}, async ({ sourceId, targetId }) => apiSend("POST", "/api/v1/soils/merge", { sourceId, targetId }));
 server.tool("list_fertilizers", "List the user's fertilizers.", async () => apiGet("/api/v1/fertilizers"));
 server.tool("create_fertilizer", "WRITE: create a fertilizer, with an optional NPK label and base dose (ml per liter of water) used to default record_fertilization's fertilizerPercent. Requires a write-scoped API key.", {
     name: z.string().min(1).max(100).describe("Fertilizer name."),

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@sebamomann/plants-mcp",
-  "version": "2.8.2",
-  "description": "MCP server for the Sprig plant app: 78 tools to read a plant collection, browse the shared global plant type catalog, log care (watering, fertilizing, repotting, refills, hydro events), edit a plant's identity/care/lifecycle status, add, propagate or merge plants, snooze a due date, check for nudges worth mentioning, manage a wishlist and notifications, watch a plant type for changes, check vacation status, read past problem diagnoses, create a location/soil/fertilizer/pot, and contribute a new species to the catalog. Read-only by default; writes need a write-scoped API key. Two tools can delete a watering/fertilization event; nothing else deletes collection history. 18 more tools read, edit, merge and review the shared global plant type catalog and the instance's operational status (queues, catalog health, activity, growth, community, trade and content aggregates) for an admin-scoped key.",
+  "version": "2.13.0",
+  "description": "MCP server for the Sprig plant app: 79 tools to read a plant collection, browse the shared global plant type catalog, log care (watering, fertilizing, repotting, refills, hydro events), edit a plant's identity/care/lifecycle status, add, propagate or merge plants, snooze a due date, check for nudges worth mentioning, manage a wishlist and notifications, watch a plant type for changes, check vacation status, read past problem diagnoses, create a location/soil/fertilizer/pot, merge a duplicate soil into another, and contribute a new species to the catalog. Read-only by default; writes need a write-scoped API key. Two tools can delete a watering/fertilization event; nothing else deletes collection history. 18 more tools read, edit, merge and review the shared global plant type catalog and the instance's operational status (queues, catalog health, activity, growth, community, trade and content aggregates) for an admin-scoped key.",
   "type": "module",
   "license": "MIT",
   "author": "sebamomann <github@sebamomann.de>",