@sebamomann/plants-mcp 2.11.0 → 2.13.0

package/CHANGELOG.md

@@ -3,6 +3,43 @@
 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

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
@@ -369,6 +383,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
@@ -534,6 +552,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 |
@@ -573,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` |
@@ -582,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

@@ -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
@@ -398,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.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": "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>",