@sebamomann/plants-mcp 2.11.0 → 3.0.0

package/CHANGELOG.md

@@ -3,6 +3,107 @@
 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.
 
+## 3.0.0 — 2026-10-04
+
+**`noFertilizerThisSeason` is renamed `fertilizingNotStarted`.** Tool count unchanged (81). A **major**
+bump — an accepted argument value was removed:
+
+- `list_care_recommendations` no longer returns `noFertilizerThisSeason` ("no feeding since the
+  season started", which fired on day one of every season). The new type `fertilizingNotStarted`
+  fires only for a plant with a fertilizer and an active fertilizing cycle that has **never** been
+  fertilized, once a full cycle has passed since feeding could have started (acquisition, the end of
+  a repotting rest, or the end of a winter pause). Cuttings are excluded.
+- `dismiss_care_recommendation`'s `type` enum: `noFertilizerThisSeason` → `fertilizingNotStarted`.
+  Old dismissals of the removed type no longer apply to anything.
+- Additive: `wateringCycleMismatch.values` gains `season` (`"summer"`/`"winter"`), the column the
+  suggestion is expressed in. The mismatch is now judged against the cycle in effect when each
+  interval started (season, gradual season ramp, controlled climate), so a season change alone no
+  longer makes a plant look off-cycle.
+- `list_notifications`: a `CHANGELOG_PUBLISHED` row may now carry `messageKey:
+  "changelogPublishedSummary"` with `values: { summary }` (that day's summary) instead of
+  `changelogPublished` with `{ count }`.
+
+## 2.16.0 — 2026-10-04
+
+**Autumn "Prüfen" checks: `list_due_care` gains `checks`, new `dismiss_transition_check`.** Tool count
+81 (was 80). A **minor** bump — one new tool and one additive response field:
+
+- `list_due_care` returns an additive `checks` array — `{ plantId, name, lastWateredAt, checkSince,
+  regularDueAt }` — for plants whose watering interval grew with the autumn season change while the
+  plant may dry out at its summer pace. A question, not a task: not in `tasks`/`counts`. Existing
+  fields are unchanged.
+- New write tool `dismiss_transition_check` (`plantId`): answers a check with "noch feucht", hiding
+  it until its regular due date without moving that date. The other answer ("dry") is
+  `record_watering`.
+
+## 2.15.0 — 2026-10-04
+
+**`update_plant_care` gains `keepWinterCare`; `get_plant` reports the effective schedule.** Tool count
+unchanged (80). A **minor** bump — one new optional argument and new response fields:
+
+- `update_plant_care` accepts `keepWinterCare: boolean`. A plant in a controlled-climate location
+  follows its summer watering and fertilizing cycle all year; `keepWinterCare: true` brings the
+  winter cycle back for both. The stored winter values are never cleared by it.
+- `get_plant` returns `keepWinterCare`, the location's `controlledClimate` (inside `location`) and a
+  new top-level `followsSummerYearRound` boolean.
+- **Behaviour change in `get_plant`:** its six schedule fields now show what scheduling actually uses.
+  For a plant that follows its summer cycle all year, the winter fields
+  (`wateringFrequencyWinterDays`, `wateringFrequencyWinter`, `fertilizingCycleWinterWeeks`) are the
+  *effective* (summer) values, not the stored winter ones. Nothing changes for plants outside a
+  controlled-climate location.
+- `update_plant_care`'s result includes `keepWinterCare`.
+
+## 2.14.0 — 2026-10-04
+
+**New tool: `update_location`; `create_location` gains `controlledClimate`.** Tool count 79 → 80
+(28 read, 34 write, 18 admin). A **minor** bump — one new write tool and one new optional argument:
+
+- `PATCH /api/v1/locations/:id` takes any of `name`, `parentId` (`null` = top level) and
+  `controlledClimate`; only the fields present change. Shares its core with the location detail
+  page's save action, so cycle checks on `parentId` behave identically.
+- `controlledClimate` marks a place with constant light and warmth (e.g. a plant cabinet): plants
+  placed directly there follow their summer watering and fertilizing cycle all year, unless the
+  plant opts back into winter care. `create_location` accepts it too.
+- `list_locations` now returns `controlledClimate` per location (a new response field — no
+  change needed by callers).
+
+## 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

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
+**81 tools** over your collection: 28 that read it, 35 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 35 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
@@ -170,7 +174,10 @@ facts (light, water, feeding need, toxicity, climate, growth, substrate/propagat
 region), keyed by the same field names `get_plant_type` uses — and its six schedule fields
 (`wateringFrequencySummerDays`/`WinterDays`, `wateringFrequencySummer`/`Winter`,
 `fertilizingCycleSummerWeeks`/`WinterWeeks`) as `{ value, source: "plant"|"type"|"none", typeValue }`
-instead of a raw value — see **Breaking changes in 2.0.0** below.
+instead of a raw value — see **Breaking changes in 2.0.0** below. They show what scheduling actually
+uses: for a plant in a controlled-climate location without `keepWinterCare`, the winter fields equal the
+summer values, and `followsSummerYearRound` is `true` (also returned: `keepWinterCare` and
+`location.controlledClimate`).
 
 ### Per-plant history
 
@@ -196,17 +203,27 @@ overrides the Apr–Sep default), `locationId`.
 
 | Tool | Endpoint | Extra arguments | Answers |
 |---|---|---|---|
-| `list_due_care` | `GET /api/v1/care/due` | `windowDays` (0–60, default 0 = that day only), `includeOverdue` (default true) | "What should I do today?" |
+| `list_due_care` | `GET /api/v1/care/due` | `windowDays` (0–60, default 0 = that day only), `includeOverdue` (default true) | "What should I do today?" Also carries the additive `checks` array (autumn "Prüfen" questions — see `dismiss_transition_check`). |
 | `list_overdue_care` | `GET /api/v1/care/overdue` | — | "What have I fallen behind on?" — most overdue first, with days late |
 | `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 |
+| `list_care_recommendations` | `GET /api/v1/care/recommendations` | none | Detected problems: cycle mismatch, chronic lateness, fertilizing never started, 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
@@ -348,7 +365,7 @@ tools** → **Catalogs** below) lets a write-scoped key add it.
 
 ## Write tools
 
-**All 31 ordinary write tools require a `write`-scoped key**; a read-only key gets HTTP 403. Every
+**All 32 ordinary write tools require a `write`-scoped key**; a read-only key gets HTTP 403. Every
 description starts with `WRITE:` so a model cannot mistake one for a read.
 
 ### Care logging
@@ -369,6 +386,10 @@ 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
@@ -401,7 +422,7 @@ it is — that backlog is not the watering's doing.
 
 | Tool | Endpoint | Arguments |
 |---|---|---|
-| `update_plant_care` | `PATCH /api/v1/plants/:id/care` | `plantId` **(required)**, plus any of `wateringMode` (`scheduled`\|`reservoir`\|`hydro`), `fertilizingMode` (`scheduled`\|`with_watering`), `wateringFrequencySummer`/`wateringFrequencyWinter` (labels), `wateringFrequencySummerDays`/`wateringFrequencyWinterDays` (1–365), `wateringNotes`, `fertilizingCycleSummerWeeks`/`fertilizingCycleWinterWeeks` (0–52), `fertilizerPercent` (0–1000), `fertilizingNotes` |
+| `update_plant_care` | `PATCH /api/v1/plants/:id/care` | `plantId` **(required)**, plus any of `wateringMode` (`scheduled`\|`reservoir`\|`hydro`), `fertilizingMode` (`scheduled`\|`with_watering`), `wateringFrequencySummer`/`wateringFrequencyWinter` (labels), `wateringFrequencySummerDays`/`wateringFrequencyWinterDays` (1–365), `wateringNotes`, `fertilizingCycleSummerWeeks`/`fertilizingCycleWinterWeeks` (0–52), `fertilizerPercent` (0–1000), `fertilizingNotes`, `keepWinterCare` (boolean — winter cycle despite a controlled-climate location) |
 | `update_plant` | `PATCH /api/v1/plants/:id` | `plantId` **(required)**, plus any of `plantTypeId`, `nickname`, `locationId`, `soilId`, `fertilizerId`, `quantity` (0–9999), `notes`, `tags` (replaces the full list), `sitterInstructions`, `parentPlantId` |
 
 Both take a `plantId` and edit **only the fields you pass** — an omitted field keeps its current
@@ -511,11 +532,20 @@ The two edit tools take an **`entryId`, not a `plantId`** — get it from `list_
 | Tool | Endpoint | Arguments |
 |---|---|---|
 | `dismiss_care_recommendation` | `POST /api/v1/care/recommendations/dismiss` | `plantId`, `type`, `fingerprint` — **all required** |
+| `dismiss_transition_check` | `POST /api/v1/care/transition-checks/dismiss` | `plantId` **(required)** — a plant listed in `checks` of `list_due_care` |
+
+`dismiss_transition_check` answers an autumn "Prüfen" check with "noch feucht": as the season changes
+to winter the watering interval grows, so a plant that dries out at its summer pace would go
+unreminded for longer. `list_due_care` lists such plants in `checks`
+(`{ plantId, name, lastWateredAt, checkSince, regularDueAt }`) from the day the summer-pace watering
+would have been due until the regular due date. The dismissal hides the check until then and never
+moves the due date; a new watering reopens the question. The other answer, "dry", is a plain
+`record_watering`.
 
 Pass all three **exactly as returned by `list_care_recommendations`**. The `fingerprint` identifies
 that specific occurrence, so dismissing one never suppresses a later, different recurrence.
 
-Dismissible `type` values: `wateringOftenLate`, `fertilizingOftenLate`, `noFertilizerThisSeason`,
+Dismissible `type` values: `wateringOftenLate`, `fertilizingOftenLate`, `fertilizingNotStarted`,
 `recentlyRepottedAvoidFertilizer`, `noRecentPhoto`, `propagationCheckDue`, `possibleDecline`.
 `wateringCycleMismatch` is **not** dismissible — it is a configuration contradiction, fixed by
 editing the plant rather than hidden.
@@ -534,6 +564,10 @@ which of those it is, and `values.otherSignalCount` says how many more also appl
 `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 |
@@ -571,8 +605,10 @@ mirror (opening the page already marks everything read).
 
 | Tool | Endpoint | Arguments |
 |---|---|---|
-| `create_location` | `POST /api/v1/locations` | `name` **(required)**, `parentId` (an owned location, to nest under) |
+| `create_location` | `POST /api/v1/locations` | `name` **(required)**, `parentId` (an owned location, to nest under), `controlledClimate` (plants there follow their summer watering/fertilizing cycle year-round unless they opt back into winter care) |
+| `update_location` | `PATCH /api/v1/locations/:id` | `locationId` **(required)**, `name`, `parentId` (`null` = top level), `controlledClimate` — only the fields passed change |
 | `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` |
@@ -582,6 +618,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

@@ -53,7 +53,7 @@ server.tool("list_plants", "List the user's plants, with optional filters. Retur
     offset: z.number().int().min(0).optional().describe("Result offset (pagination)."),
     sort: z.enum(["displayName", "createdAt", "updatedAt", "acquiredAt"]).optional().describe("Sort key. 'displayName' sorts by the plant's resolved name (nickname, or its type's name); the rest sort newest first."),
 }, async (args) => apiGet("/api/v1/plants", args));
-server.tool("get_plant", "Get one plant with full detail: identity (type, nickname, display name, botanical name, unidentified state — see 'type'), typeFacts (the type's effective light/water/feeding need, toxicity, climate, growth, substrate/propagation, family/native region — using the catalog field keys from get_plant_type), catalogs (location, soil, fertilizer), care config, and recent event summaries. The six schedule fields (wateringFrequencySummerDays/WinterDays, wateringFrequencySummer/Winter, fertilizingCycleSummerWeeks/WinterWeeks) are each { value, source: 'plant'|'type'|'none', typeValue } — value is what scheduling/display use, source says where it came from, typeValue is what the type would say even when the plant overrides it.", { id: z.number().int().describe("Plant id.") }, async ({ id }) => apiGet(`/api/v1/plants/${id}`));
+server.tool("get_plant", "Get one plant with full detail: identity (type, nickname, display name, botanical name, unidentified state — see 'type'), typeFacts (the type's effective light/water/feeding need, toxicity, climate, growth, substrate/propagation, family/native region — using the catalog field keys from get_plant_type), catalogs (location, soil, fertilizer), care config, and recent event summaries. The six schedule fields (wateringFrequencySummerDays/WinterDays, wateringFrequencySummer/Winter, fertilizingCycleSummerWeeks/WinterWeeks) are each { value, source: 'plant'|'type'|'none', typeValue } — value is what scheduling/display use, source says where it came from, typeValue is what the type would say even when the plant overrides it. For a plant in a controlled-climate location (location.controlledClimate) that has not set keepWinterCare, followsSummerYearRound is true and the three winter schedule fields show the SUMMER values — the plant follows its summer cycle all year (the raw stored winter values are kept and return when keepWinterCare is set or the plant moves elsewhere).", { id: z.number().int().describe("Plant id.") }, async ({ id }) => apiGet(`/api/v1/plants/${id}`));
 // --- Events connected to a plant -------------------------------------------
 const eventArgs = {
     id: z.number().int().describe("Plant id."),
@@ -84,7 +84,7 @@ const careArgs = {
         .describe("Override the season (Apr–Sep is summer). Defaults to the season of `date`."),
     locationId: z.number().int().optional().describe("Only consider plants in this location."),
 };
-server.tool("list_due_care", "What needs water or fertilizer now: overdue work plus anything due on the given day. Use `windowDays` to look ahead. This is the right tool for 'what should I do today?'. A fertilizing entry carries `wateringAlignedOn` (YYYY-MM-DD, null when absent) when the app's calendar has grouped that feeding with a watering; `windowDays`/`includeOverdue` are judged by that day, not the feeding's own `nextDue` — see `get_care_calendar`'s description for the full rule.", {
+server.tool("list_due_care", "What needs water or fertilizer now: overdue work plus anything due on the given day. Use `windowDays` to look ahead. This is the right tool for 'what should I do today?'. A fertilizing entry carries `wateringAlignedOn` (YYYY-MM-DD, null when absent) when the app's calendar has grouped that feeding with a watering; `windowDays`/`includeOverdue` are judged by that day, not the feeding's own `nextDue` — see `get_care_calendar`'s description for the full rule. The additive `checks` array lists autumn 'Prüfen' questions — { plantId, name, lastWateredAt, checkSince, regularDueAt } — for plants that dry out at their summer pace while the season change has stretched their interval: the summer-pace date (`checkSince`) has passed but the regular due date (`regularDueAt`) has not. A check is a question ('is the soil dry?'), not a task — it is not in `tasks`/`counts`. Answer 'dry' with `record_watering`, 'still moist' with `dismiss_transition_check`.", {
     ...careArgs,
     windowDays: z
         .number()
@@ -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
@@ -188,7 +188,7 @@ server.tool("snooze_care", "WRITE: postpone a plant's next watering or fertilizi
     originalDueAt: z.string().describe("The due date being pushed out, e.g. from list_due_care's nextDue for this plant/careType."),
     note: z.string().max(160).optional().describe("Free-text reason, e.g. 'away for the week'."),
 }, async (args) => apiSend("POST", "/api/v1/care/snooze", { ...args }));
-server.tool("update_plant_care", "WRITE: edit a plant's care schedule — watering mode, days/labels, fertilizing mode, cycles and percent, and the watering/fertilizing notes. Omitted fields keep their current value. null on wateringFrequencySummerDays/WinterDays, wateringFrequencySummer/Winter, or fertilizingCycleSummerWeeks/WinterWeeks means 'follow the type' — the plant's effective schedule then falls back to its type's suggested value (see get_plant's typeFacts / the schedule fields' typeValue) instead of having no schedule at all; a value equal to the type's suggested value is stored the same way (it follows the type). null on wateringNotes/fertilizingNotes just clears the note. Watering fields are ignored while the plant's watering isn't on a schedule (reservoir/hydro), and the fertilizing-cycle fields are ignored while it fertilizes with every watering — there's no cycle to configure in either case. If wateringMode/fertilizingMode is part of this same call, that check runs against the NEW mode, not the plant's current one — e.g. switching to 'reservoir' while also passing a watering cycle ignores that cycle. sunRequirement/waterRequirement are no longer settable here — light and water need are type-only facts now (get_plant's typeFacts, or get_plant_type). Use this (not update_plant) to fix a 'wateringCycleMismatch' recommendation where the mode itself is wrong. Requires a write-scoped API key.", {
+server.tool("update_plant_care", "WRITE: edit a plant's care schedule — watering mode, days/labels, fertilizing mode, cycles and percent, and the watering/fertilizing notes. Omitted fields keep their current value. null on wateringFrequencySummerDays/WinterDays, wateringFrequencySummer/Winter, or fertilizingCycleSummerWeeks/WinterWeeks means 'follow the type' — the plant's effective schedule then falls back to its type's suggested value (see get_plant's typeFacts / the schedule fields' typeValue) instead of having no schedule at all; a value equal to the type's suggested value is stored the same way (it follows the type). null on wateringNotes/fertilizingNotes just clears the note. Watering fields are ignored while the plant's watering isn't on a schedule (reservoir/hydro), and the fertilizing-cycle fields are ignored while it fertilizes with every watering — there's no cycle to configure in either case. If wateringMode/fertilizingMode is part of this same call, that check runs against the NEW mode, not the plant's current one — e.g. switching to 'reservoir' while also passing a watering cycle ignores that cycle. sunRequirement/waterRequirement are no longer settable here — light and water need are type-only facts now (get_plant's typeFacts, or get_plant_type). Use this (not update_plant) to fix a 'wateringCycleMismatch' recommendation where the mode itself is wrong. keepWinterCare brings the winter cycle back for a plant in a controlled-climate location (which otherwise follows its summer cycle all year, see get_plant's followsSummerYearRound) — it governs both watering and fertilizing and has no effect elsewhere; the stored winter values are never cleared by it. Requires a write-scoped API key.", {
     plantId: z.number().int().positive().describe("Plant id."),
     wateringMode: z.enum(["scheduled", "reservoir", "hydro"]).optional().describe("How this plant is watered: on a schedule, from a reservoir, or in water/hydro culture."),
     fertilizingMode: z.enum(["scheduled", "with_watering"]).optional().describe("How this plant is fertilized: on its own cycle, or automatically with every watering."),
@@ -201,6 +201,7 @@ server.tool("update_plant_care", "WRITE: edit a plant's care schedule — wateri
     fertilizingCycleWinterWeeks: z.number().int().min(0).max(52).nullable().optional().describe("Winter fertilizing interval in weeks. null follows the type's suggested weeks. Ignored while fertilizing is 'with every watering'."),
     fertilizerPercent: z.number().int().min(0).max(1000).optional().describe("Strength as a percentage of the base dose."),
     fertilizingNotes: z.string().max(500).nullable().optional().describe("Free-text fertilizing notes."),
+    keepWinterCare: z.boolean().optional().describe("true: use the winter cycle despite a controlled-climate location; false: follow the summer cycle all year there. Only matters while the plant stands in a location with controlledClimate."),
 }, async ({ plantId, ...body }) => apiSend("PATCH", `/api/v1/plants/${plantId}/care`, body));
 server.tool("update_plant", "WRITE: edit a plant's type, nickname, location, soil, fertilizer, quantity, notes, tags, sitter instructions, or parent plant. Omitted fields keep their current value; null unassigns a catalog entry, clears notes/instructions, empties the tag list, or detaches the plant from its parent — and for plantTypeId, makes the plant 'unidentified'. nickname is required whenever the plant's state after this edit has no type (whether because plantTypeId is set to null here, or was already null and nickname isn't being set to something non-empty) — see plantIdentity's validatePlantNickname. Requires a write-scoped API key.", {
     plantId: z.number().int().positive().describe("Plant id."),
@@ -239,7 +240,7 @@ server.tool("dismiss_care_recommendation", "WRITE: hide one care recommendation,
         .enum([
         "wateringOftenLate",
         "fertilizingOftenLate",
-        "noFertilizerThisSeason",
+        "fertilizingNotStarted",
         "recentlyRepottedAvoidFertilizer",
         "noRecentPhoto",
         "propagationCheckDue",
@@ -248,6 +249,9 @@ server.tool("dismiss_care_recommendation", "WRITE: hide one care recommendation,
         .describe("Recommendation type, from list_care_recommendations."),
     fingerprint: z.string().min(1).describe("Occurrence fingerprint, from list_care_recommendations."),
 }, async (args) => apiSend("POST", "/api/v1/care/recommendations/dismiss", { ...args }));
+server.tool("dismiss_transition_check", "WRITE: answer an autumn 'Prüfen' check with 'noch feucht' (still moist) — hides that plant's check until its regular due date, without moving the due date. Pass the plantId of an entry in `checks` of list_due_care. The answer is tied to the plant's last watering, so a new watering reopens the question next autumn/interval. For the other answer — the soil is dry — just call `record_watering`: a normal watering makes the check disappear. Requires a write-scoped API key.", {
+    plantId: z.number().int().positive().describe("Plant id, from `checks` of list_due_care."),
+}, async (args) => apiSend("POST", "/api/v1/care/transition-checks/dismiss", { ...args }));
 // --- Deleting events ---------------------------------------------------------
 /**
  * The only destructive tools in this server. Everything else — plants,
@@ -388,7 +392,14 @@ server.tool("create_plant_type", "WRITE: add a species/cultivar the shared globa
 server.tool("create_location", "WRITE: create a location — the same 'create inline' picker on the plant form. Never conflicts with an existing owned catalog entry: a duplicate name is rejected by the underlying unique constraint, surfaced as an error. Requires a write-scoped API key.", {
     name: z.string().min(1).max(100).describe("Location name."),
     parentId: z.number().int().positive().optional().describe("An owned location id to nest this one under (from list_locations). Omit for a top-level location."),
-}, async ({ name, parentId }) => apiSend("POST", "/api/v1/locations", { name, parentId }));
+    controlledClimate: z.boolean().optional().describe("True for a place with constant light and warmth all year (e.g. a plant cabinet with a grow light): plants placed directly here follow their summer watering and fertilizing cycle year-round, unless the plant opts back into winter care. Omit for false."),
+}, async ({ name, parentId, controlledClimate }) => apiSend("POST", "/api/v1/locations", { name, parentId, controlledClimate }));
+server.tool("update_location", "WRITE: rename, move or change the climate setting of an owned location. Only the fields you pass change. Requires a write-scoped API key.", {
+    locationId: z.number().int().positive().describe("The location id (from list_locations)."),
+    name: z.string().min(1).max(100).optional().describe("New name."),
+    parentId: z.number().int().positive().nullable().optional().describe("An owned location id to nest this one under; null moves it to the top level. Omit to keep the current parent. Cycles are rejected."),
+    controlledClimate: z.boolean().optional().describe("True: plants placed directly in this location (not its sublocations) follow their summer watering and fertilizing cycle year-round, unless the plant opts back into winter care. False: normal seasonal cycle again. Omit to keep the current setting."),
+}, async ({ locationId, name, parentId, controlledClimate }) => apiSend("PATCH", `/api/v1/locations/${locationId}`, { name, parentId, controlledClimate }));
 server.tool("list_soils", "List the user's soils.", async () => apiGet("/api/v1/soils"));
 server.tool("create_soil", "WRITE: create a soil mix, optionally with components (name + parts) — mirrors the app's soil mix editor. Each component is matched or created by name under the caller's account. Requires a write-scoped API key.", {
     name: z.string().min(1).max(100).describe("Soil name."),
@@ -398,6 +409,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.11.0",
-  "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": "3.0.0",
+  "description": "MCP server for the Sprig plant app: 81 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, answer an autumn watering check, check for nudges worth mentioning, manage a wishlist and notifications, watch a plant type for changes, check vacation status, read past problem diagnoses, create or update a location (incl. its controlled-climate setting), create a 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>",