@sebamomann/plants-mcp 2.13.0 → 3.0.0

package/CHANGELOG.md

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

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
 
-**79 tools** over your collection: 28 that read it, 33 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,
@@ -112,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 33 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
@@ -174,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
 
@@ -200,10 +203,10 @@ 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 |
 
 Five things to know when reading schedule results:
 
@@ -362,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
@@ -419,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
@@ -529,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.
@@ -593,7 +605,8 @@ 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) |

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()
@@ -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."),

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@sebamomann/plants-mcp",
-  "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.",
+  "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>",