@sebamomann/plants-mcp 1.9.0 → 2.5.0

package/CHANGELOG.md

@@ -3,6 +3,154 @@
 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.5.0 — 2026-09-16
+
+**Past problem diagnoses.** 76 tools registered overall (27 read, 31 write, 18 admin). A **minor**
+bump — one new tool, nothing renamed or removed:
+
+- `list_diagnoses` — a plant's guided problem diagnoses ("Problem eingrenzen"), newest first, with
+  the symptom, every question and the answer given, the ranked possible causes, the action the user
+  picked, and the resolution. Active and resolved runs alike, since a resolved run stays readable by
+  design. Stored i18n keys are resolved to plain English for the caller. Running the flow itself
+  stays UI-only — see `docs/mcp-server.md`.
+
+## 2.4.0 — 2026-09-16
+
+**Admin dashboard status.** 75 tools registered overall (26 read, 31 write, 18 admin). A **minor**
+bump — one new tool, nothing renamed or removed:
+
+- `admin_get_dashboard_status` — the same aggregate the app's own `/admin` page shows in one call:
+  every review queue's count and the age of its oldest item, catalog health (verified/unverified
+  split, types with no care values, orphan cultivars, types with no plants, low-completeness types,
+  unidentified plants), weekly activity (new plants, care events logged, contributions
+  submitted/decided), and operational facts (push-enabled users, pending email verifications,
+  active API keys, applied migration count — counts only, never a secret). No arguments. Sits
+  outside the catalog surface below (it isn't under `/api/v1/admin/plant-types/*`) — see
+  `docs/mcp-server.md`'s "Admin dashboard status".
+
+## 2.3.0 — 2026-09-16
+
+**Write parity: repotting, refills, hydro events, snoozing, lifecycle status, catalog
+contributions, and notifications.** 74 tools registered overall (26 read, 31 write, 17 admin). A
+**minor** bump — nine new tools, nothing renamed or removed:
+
+- `record_repotting` — log a repotting (pot/soil/size), re-deriving the plant's soil and syncing
+  care mode on a self-watering pot change, the same as the app's own repotting form.
+- `record_refill` — log a reservoir refill with fertilizer/percent, for a `reservoir`-mode plant.
+- `record_hydro_event` — log a hydro-culture top-up or solution change.
+- `snooze_care` — postpone a plant's next watering or fertilizing due date by a fixed duration (1,
+  3, 7, or 14 days).
+- `set_plant_status` — set a plant's status to `LIVING`, `DEAD`, or `LOST` (deliberately narrower
+  than the app's full status range — see `docs/mcp-server.md`'s "Lifecycle status changes are a
+  safe subset").
+- `set_plant_reference` — flip a plant between `LIVING` and `EXTERNAL` (reference-only);
+  reversible.
+- `create_plant_type` — the user-facing counterpart to `admin_create_plant_type`: add a
+  species/cultivar the catalog is missing, always `UNVERIFIED`. Runs the plant-type picker's
+  duplicate check server-side (there's no client screen to have shown it first) — a likely
+  duplicate blocks creation (`{ created: false, duplicates }`) unless `confirmDespiteDuplicates:
+  true`. `propose_plant_type_change` stays on the roadmap; it needs its own design pass.
+- `list_notifications` — the caller's notification centre, newest first, cursor-paginated.
+  Sale/trade notifications are always excluded, the same permanent exclusion
+  `list_recent_activity` applies.
+- `mark_notifications_read` — mark every unread notification read.
+
+## 2.2.0 — 2026-09-16
+
+**Catalog creation, pots, and mode-agnostic vacation status.** 65 tools registered overall (25
+read, 23 write, 17 admin). A **minor** bump — six new tools, nothing renamed or removed:
+
+- `create_location` — create a location, optionally nested under an owned parent.
+- `create_soil` — create a soil mix, optionally with components (each upserted by name).
+- `create_fertilizer` — create a fertilizer, with an optional NPK label and base dose.
+- `list_pots` — the caller's own pots plus the shared default pots, with reference links and
+  recorded sizes.
+- `create_pot` — create a pot, optionally with reference links. Pot *sizes* still have no create
+  tool.
+- `get_vacation_status` — whether the caller has a current or upcoming vacation in **either** mode
+  (`sitter` or `shift`), with just id/mode/date-range/active-state/plant-count — the mode-agnostic
+  counterpart `sitter_briefing` never provided (that tool only ever reports a `sitter`-mode
+  vacation's full detail).
+
+The four create tools reuse the same cores the plant form's "create inline" pickers use
+(`app/_lib/plants/resourceCreation.ts`), so a location/soil/fertilizer/pot created over MCP gets
+identical validation and duplicate-name handling to one created in the app.
+
+## 2.1.0 — 2026-09-16
+
+**Watch a plant type.** 59 tools registered overall (23 read, 19 write, 17 admin). A **minor**
+bump — three new tools, nothing renamed or removed:
+
+- `list_watched_types` — the caller's "watch a type" subscriptions: type id, display/botanical
+  name, status.
+- `watch_type` — subscribe to a global catalog type. Never creates a second watch for a type
+  already watched (`duplicate: true`), the same convention as `add_to_wishlist`.
+- `unwatch_type` — remove a subscription. Not counted as a destructive delete, the same reasoning
+  as `remove_from_wishlist` — a watch is a personal subscription with no history to lose.
+
+A watcher is notified **in-app only** (the Neuigkeiten centre) whenever a watched type's fields,
+identity, names, verification status or approved photos change — there is no MCP read for
+notifications yet (see `docs/mcp-server.md`'s roadmap).
+
+## 2.0.0 — 2026-09-15
+
+**Plant identity moves to a shared, community-maintained global catalog.** 56 tools registered
+overall (22 read, 17 write, 17 admin). This is a **major** bump — see `docs/mcp-server.md`'s
+"Breaking changes in 2.0.0" section for the full list; summary:
+
+- **`plantTypeId` is now a global catalog id everywhere it appears** (`list_plants`, `get_plant`,
+  `create_plant`, `update_plant`) — a legacy per-user type id cached before this release does not
+  refer to the same row. Re-resolve any cached id via `list_plant_types`/`search_plant_types`.
+- **`list_plant_types` now serves the shared global catalog**, not a per-user list.
+- **New tools:**
+  - `search_plant_types` — fuzzy search the global catalog by name (any locale) or botanical name.
+    Same underlying endpoint as `list_plant_types`; `query` is required here, optional there.
+  - `get_plant_type` — one type's fact sheet: identity, names by locale, parent/cultivar children,
+    effective catalog facts with each field's source (`"own"`/`"inherited"`), approved image URLs,
+    and the caller's own plant count. A `MERGED` id transparently resolves to its survivor.
+- **`create_plant`'s `plantTypeId` is now optional** — omit it (or pass `null`) to add an
+  "unidentified" plant; `nickname` is then required, matching the app's plant form.
+- **`update_plant` gained `plantTypeId` and `nickname`** — re-identify a plant, or make it
+  unidentified (`plantTypeId: null` + a `nickname`).
+- **`get_plant`'s `plantType` field is replaced by `type`** —
+  `{ plantTypeId, nickname, displayName, botanicalName, typeStatus, isUnidentified }`. `list_plants`
+  rows changed the same way.
+- **`get_plant` gained `typeFacts`** — the type's effective light/water/feeding need, toxicity,
+  climate, growth, substrate/propagation, and family/native region.
+- **`get_plant`'s six schedule fields are no longer raw values** — each is now
+  `{ value, source: "plant"|"type"|"none", typeValue }`.
+- **`update_plant_care` no longer accepts `sunRequirement`/`waterRequirement`** — both are type-only
+  facts now, read via `get_plant`'s `typeFacts` or `get_plant_type`.
+- **`null` on `update_plant_care`'s watering/fertilizing-cycle fields now means "follow the type"**
+  instead of "no schedule" — the tool's zod schema now accepts `null` for those four fields, which
+  it previously rejected. A value equal to the type's value is stored as `null` too, so the plant
+  keeps following later changes to the type; `update_plant` switching `plantTypeId` moves values
+  that followed the old type onto the new one (or, to no type, writes them in).
+- **`list_plants`'s `sort=commonName` is renamed `sort=displayName`** (resolved in memory — no
+  longer a database column) and its `search` now matches the plant's nickname and its type's names
+  in every locale, not a legacy `PlantType.commonName` column.
+- **`GlobalPlantTypeStatus` gained a `REJECTED` value** — an admin can reject a user-created
+  `UNVERIFIED` type in the app (required note, plus a merge/unlink outcome for its plants); the
+  row persists, analogous to `MERGED`. `list_plant_types`/`search_plant_types` never return one;
+  `get_plant_type` on a rejected id behaves like `MERGED` (redirects when the outcome was a merge).
+  `admin_get_plant_type`'s `status` can now be `"REJECTED"`. No new tool triggers this yet — see
+  `docs/mcp-server.md`'s roadmap (`admin_reject_plant_type`).
+
+## 1.10.0 — 2026-09-15
+
+**Wishlist tools.** Four tools total — 54 registered overall (20 read, 17 write, 17 admin):
+
+- `list_wishlist` — the caller's wishlist: each wish's plant type (display/botanical name,
+  `typeStatus`) when set, or a free-text `name` fallback, plus dated `notes` and
+  `ownedLivingCount` (how many `LIVING` plants of that type the caller already has).
+- `add_to_wishlist` (write) — add a wish by `plantTypeId` or free-text `name`. Never creates a
+  second wish for a type the caller already has — returns the existing one instead
+  (`duplicate: true`).
+- `add_wishlist_note` (write) — add a dated note to a wish (price, where to get it, a shop link).
+- `remove_from_wishlist` (write) — remove a wish. Not counted as a "destructive" tool in the sense
+  `delete_watering_event`/`delete_fertilization_event` are — a wish carries no collection history,
+  and is trivially re-added.
+
 ## 1.9.0 — 2026-09-15
 
 **Admin keys can now read, directly edit, merge, and review the shared global plant type catalog.**

package/README.md

@@ -60,17 +60,24 @@ needs a running Sprig instance and an API key from it. Start at the
 
 ## What an assistant can do
 
-**50 tools** over your collection: 19 that read it, 14 that write to it. **17 admin tools** are also
+**76 tools** over your collection: 27 that read it, 31 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, and (6 read-only, 11
-that write) reading, directly editing, merging, and reviewing proposals and duplicate candidates in
-that catalog. See **Admin tools** below.
-
-Reads cover plants, watering and fertilization history, the full care timeline, photo metadata,
-health entries, the derived care schedule, collection-wide activity, and the lookup catalogs.
-Writes cover recording waterings and fertilizings, health notes, dismissing care recommendations,
-editing a plant's care schedule or settings, adding a plant, propagating one, merging plants
-together and reversing that merge, and deleting a watering or fertilization event.
+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,
+11 that write) checking the instance's own operational status. See **Admin tools** below.
+
+Reads cover plants, the shared global plant type catalog, watering and fertilization history, the
+full care timeline, photo metadata, health entries, the derived care schedule, collection-wide
+activity, the wishlist, watched types, notifications, vacation status, and the lookup catalogs
+(including pots). Writes cover recording waterings, fertilizings, repottings, reservoir refills and
+hydro events, snoozing a due date, health notes, dismissing care recommendations, editing a plant's
+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.
+
+**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`.
 
 **Deleting a plant, a photo, or a catalog entry is not possible from here** — that stays UI-only.
 `delete_watering_event` and `delete_fertilization_event` are the two exceptions (see **What this
@@ -102,11 +109,11 @@ 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 19 read tools.
-- **`write`** — opt-in when you create the key. Gates the 14 write tools.
+- **`read`** — on every key. Gates all 27 read tools.
+- **`write`** — opt-in when you create the key. Gates the 31 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 17 admin catalog tools — 6 read-only, 11 that write — see **Admin tools** below. `admin` alone
+  the 18 admin catalog tools — 7 read-only, 11 that write — see **Admin tools** below. `admin` alone
   is enough for the write ones too (not also `write` — the three scopes are independent grants). An
   admin's key is created with `read`+`write`+`admin` together, so it also works with every ordinary
   tool.
@@ -124,11 +131,14 @@ point of the scope split.
 
 Not oversights — deliberate limits:
 
-- **No deletes, except two.** Deleting a plant, a photo, or a catalog entry stays UI-only — the
-  blast radius of a misunderstood delete there is a multi-year history, and retiring a plant is a
-  *status* change instead. `delete_watering_event` and `delete_fertilization_event` are the
-  exceptions: a mis-logged event has no such reversible alternative, so those two are destructive
-  and **cannot be undone**.
+- **No deletes of collection history, except two.** Deleting a plant, a photo, or a catalog entry
+  stays UI-only — the blast radius of a misunderstood delete there is a multi-year history, and
+  retiring a plant is a *status* change instead. `delete_watering_event` and
+  `delete_fertilization_event` are the exceptions: a mis-logged event has no such reversible
+  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.
 - **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
@@ -143,17 +153,27 @@ Not oversights — deliberate limits:
 | Tool | Endpoint | Arguments |
 |---|---|---|
 | `whoami` | `GET /api/v1/me` | none — who the key belongs to |
-| `list_plants` | `GET /api/v1/plants` | all optional: `status`, `lifecycle`, `locationId`, `plantTypeId`, `soilId`, `fertilizerId`, `tag` (exact match), `search` (type name / notes), `limit` (1–200), `offset`, `sort` |
-| `get_plant` | `GET /api/v1/plants/:id` | `id` **(required)** — full detail: catalogs, care config, lineage, recent events |
+| `list_plants` | `GET /api/v1/plants` | all optional: `status`, `lifecycle`, `locationId`, `plantTypeId` (a **global** catalog id), `soilId`, `fertilizerId`, `tag` (exact match), `search` (nickname / type names / notes), `limit` (1–200), `offset`, `sort` (`displayName`\|`createdAt`\|`updatedAt`\|`acquiredAt`) |
+| `get_plant` | `GET /api/v1/plants/:id` | `id` **(required)** — full detail: identity (`type`), `typeFacts`, catalogs, care config, lineage, recent events |
 
 `status` is one of `LIVING`, `DEAD`, `GIFTED`, `LOST`, `SOLD`, `TRADED`, `MERGED`, `SPLIT`,
 `EXTERNAL`; `lifecycle` is `PROPAGATING` or `ESTABLISHED`. `EXTERNAL` is a **reference plant** —
 somebody else's plant, recorded only as an anchor for propagation lineage. It is never cared for,
 never appears in due/overdue care, and is excluded from `collection_stats`.
 
+Each plant's identity is a `type` object (replacing the old `plantType`):
+`{ plantTypeId, nickname, displayName, botanicalName, typeStatus, isUnidentified }`.
+`plantTypeId` is `null` for an "unidentified" plant — one with no catalog type, just a `nickname`.
+`get_plant` additionally returns `typeFacts` — the type's effective (inheritance-resolved) catalog
+facts (light, water, feeding need, toxicity, climate, growth, substrate/propagation, family/native
+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.
+
 ### Per-plant history
 
-All five take the same arguments: `id` **(required)**, `limit` (1–500), `offset`. Newest first.
+All six take the same arguments: `id` **(required)**, `limit` (1–500), `offset`. Newest first.
 
 | Tool | Endpoint | Returns |
 |---|---|---|
@@ -162,6 +182,7 @@ All five take the same arguments: `id` **(required)**, `limit` (1–500), `offse
 | `list_care_events` | `GET /api/v1/plants/:id/events` | Combined timeline — watering, fertilization, refill, hydro, potting, snoozes — each tagged with a `kind` |
 | `list_photos` | `GET /api/v1/plants/:id/photos` | Photo **metadata** (urls, `takenAt`). Not the images themselves. |
 | `list_health_entries` | `GET /api/v1/plants/:id/health` | Health and AI-analysis entries. Source of the `entryId` the health write tools take. |
+| `list_diagnoses` | `GET /api/v1/plants/:id/diagnoses` | Past guided-diagnosis runs ("Problem eingrenzen"): symptom, Q&A, ranked possible causes, chosen action, AI opinion if any — resolved to plain English. |
 
 ### Care schedule
 
@@ -213,6 +234,7 @@ page.
 | Tool | Endpoint | Arguments |
 |---|---|---|
 | `sitter_briefing` | `GET /api/v1/vacation/sitter-briefing` | `locationId` (optional) |
+| `get_vacation_status` | `GET /api/v1/vacation/status` | none |
 
 Printable care sheet for the caller's current or next `sitter`-mode vacation: per-plant sitter
 instructions, watering notes, cycle and next-due state, and the day-by-day watering schedule for
@@ -220,23 +242,90 @@ the trip. Returns `{ hasVacation: false }` when there's no upcoming or running s
 this tool never creates or modifies one. `locationId` narrows the plant list to one location; the
 schedule always covers the whole vacation.
 
+`get_vacation_status` is the lighter, mode-agnostic counterpart: it reports a current or upcoming
+vacation in **either** mode (`sitter` or `shift`), with just `{ id, mode, startsOn, endsOn, isActive,
+isUpcoming, plantCount }` — no per-plant detail or schedule. Use `sitter_briefing` for the full
+sitter sheet; use this one just to know whether a vacation (of either mode) exists at all.
+
+### Wishlist
+
+| Tool | Endpoint | Arguments |
+|---|---|---|
+| `list_wishlist` | `GET /api/v1/wishlist` | none |
+
+Plants the caller wants but doesn't own yet. Each entry carries `plantTypeId` (when it's a global
+catalog type, with its display/botanical name and `typeStatus`) or a free-text `name` fallback for
+a species not yet in the catalog, a `notes` array (dated, e.g. price or where to get it), and
+`ownedLivingCount` — how many `LIVING` plants of that type the caller already has.
+
+### Watched types
+
+| Tool | Endpoint | Arguments |
+|---|---|---|
+| `list_watched_types` | `GET /api/v1/plant-type-watches` | none |
+
+Global catalog types the caller subscribed to via the "Art beobachten" eye toggle (the wishlist
+heart's sibling affordance). Each entry carries `plantTypeId`, `typeDisplayName`, `botanicalName`,
+`cultivar` and `typeStatus`. A watcher gets notified in-app (the Neuigkeiten centre — see
+**Notifications** below) whenever an admin edits the type's fields, identity or names, verifies it,
+merges it into another type, or a new photo is approved for it.
+
+### Notifications
+
+| Tool | Endpoint | Arguments |
+|---|---|---|
+| `list_notifications` | `GET /api/v1/notifications` | `cursor` (optional, from a previous call's `nextCursor`) |
+
+The caller's notification centre, newest first, cursor-paginated. Each item is `{ id, kind,
+createdAt, readAt, href, messageKey, values, actor }` — `messageKey`/`values` are the same
+i18n key + interpolation data the in-app page renders through next-intl, not pre-rendered text, so
+the exact sentence depends on locale rather than being hardcoded here. `actor` (when the event has
+one) is the user who triggered it — `{ id, username, avatarUrl }`. Sale/trade notifications
+(`SALE_*` kinds) are always excluded, the same permanent exclusion `list_recent_activity` applies.
+
 ### Catalogs
 
-For resolving the ids the filters take. No arguments.
+For resolving the ids the filters take.
 
-| Tool | Endpoint |
-|---|---|
-| `list_locations` | `GET /api/v1/locations` |
-| `list_plant_types` | `GET /api/v1/plant-types` |
-| `list_soils` | `GET /api/v1/soils` |
-| `list_fertilizers` | `GET /api/v1/fertilizers` |
+| Tool | Endpoint | Arguments |
+|---|---|---|
+| `list_locations` | `GET /api/v1/locations` | none |
+| `list_plant_types` | `GET /api/v1/plant-types` | all optional: `query` (fuzzy search), `status` (`UNVERIFIED`\|`VERIFIED`), `inMyCollection`, `limit` (1–200), `offset` |
+| `search_plant_types` | `GET /api/v1/plant-types` | `query` **(required)**, plus the same optional filters/paging as `list_plant_types` |
+| `get_plant_type` | `GET /api/v1/plant-types/:id` | `id` **(required)** — one type's fact sheet |
+| `list_soils` | `GET /api/v1/soils` | none |
+| `list_fertilizers` | `GET /api/v1/fertilizers` | none |
+| `list_pots` | `GET /api/v1/pots` | none |
+
+`list_pots` returns the caller's own pots plus the shared default pots (defaults first), each with
+its reference links and recorded sizes.
+
+**`list_plant_types` is the shared, community-maintained global catalog** — the same for every
+user, not a per-user list. `list_plant_types` and `search_plant_types` are the same endpoint and
+reader; they exist as two tools because browsing (no `query`) and searching (`query` required) are
+different intents for a model to reach for, even though the underlying call is identical.
+`inMyCollection: true` narrows to types the caller has at least one `LIVING` plant of — each row's
+`viewerPlantsCount` says how many. A `MERGED` or `REJECTED` type never appears in either list.
+
+`get_plant_type` returns `{ id, status, mergedIntoId, displayName, botanicalName, names, parent,
+children, facts: { values, sources }, images, viewerPlantsCount, changeLog }`. `facts.values` are
+the effective (inheritance-resolved) catalog values — the same field keys `get_plant`'s `typeFacts`
+uses; `facts.sources` says `"own"` or `"inherited"` per field. `images` are approved URLs only. A
+`MERGED` id **transparently resolves to its survivor** here (unlike the admin
+`admin_get_plant_type`, which returns the redirect stub) — there is nothing for a non-admin caller
+to do with the stub itself. A `REJECTED` id behaves the same way when its outcome was a merge
+(`mergedIntoId` set); otherwise it resolves to the type's own now-`REJECTED` row, since there's no
+survivor to point to.
+
+A species missing from this catalog isn't just a read gap: `create_plant_type` (in **Write
+tools** → **Catalogs** below) lets a write-scoped key add it.
 
 ---
 
 ## Write tools
 
-**All ten 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.
+**All 31 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
 
@@ -244,6 +333,10 @@ 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_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`), `durationDays` (1, 3, 7, or 14), `originalDueAt` **(all required)**, `note` |
 
 `record_watering` mirrors a one-click watering in the app: reservoir and hydro plants are recorded
 as a refill / top-up automatically, and plants configured to fertilize with watering also get a
@@ -251,27 +344,57 @@ 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.
+thing per plant. `record_refill` and `record_hydro_event` default the same two fields the same way.
+
+`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.
+
+`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
+app's own refill form, it also logs a fertilization when the plant feeds with every watering.
+
+`record_hydro_event` logs a water top-up (default `kind`) or a full solution change for a
+hydro-cultured plant.
+
+`snooze_care` postpones a plant's next watering or fertilizing due date — the same picker the care
+hub offers. `originalDueAt` is the due date being pushed out (`nextDue` from `list_due_care`/
+`get_care_calendar` for that plant/careType), not today's date.
 
 ### Plant edits
 
 | 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`), `sunRequirement` (1–4), `waterRequirement` (1–3), `wateringFrequencySummer`/`wateringFrequencyWinter` (labels), `wateringFrequencySummerDays`/`wateringFrequencyWinterDays` (1–365), `wateringNotes`, `fertilizingCycleSummerWeeks`/`fertilizingCycleWinterWeeks` (0–52), `fertilizerPercent` (0–1000), `fertilizingNotes` |
-| `update_plant` | `PATCH /api/v1/plants/:id` | `plantId` **(required)**, plus any of `locationId`, `soilId`, `fertilizerId`, `quantity` (0–9999), `notes`, `tags` (replaces the full list), `sitterInstructions`, `parentPlantId` |
+| `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` | `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
 value, `null` clears it (unassigns a catalog id, or blanks a text field).
 
-`update_plant_care`'s watering fields (other than `sunRequirement`) only take effect while the
-plant's watering is on a schedule — a reservoir/hydro plant has no cycle for them to configure, so
-they're silently ignored for one. The fertilizing-cycle fields are likewise ignored while the plant
-fertilizes with every watering rather than on its own cycle. Passing `wateringMode`/`fertilizingMode`
-in the **same call** as the fields they gate checks against the *new* mode, not the current one — so
-switching a plant to `"reservoir"` while also setting a watering cycle just drops that cycle rather
-than saving it. `careMode` (a legacy mirror of `wateringMode`) updates itself; it isn't a field you set.
-This is also the tool that actually fixes a `wateringCycleMismatch` recommendation — that
-recommendation's own text says "edit the plant," and the mode causing the mismatch lives here.
+**`update_plant_care` no longer accepts `sunRequirement`/`waterRequirement`** — light and water need
+are type-only facts now (`get_plant`'s `typeFacts`, or `get_plant_type`). `null` on
+`wateringFrequencySummerDays`/`WinterDays`, `wateringFrequencySummer`/`Winter`, or
+`fertilizingCycleSummerWeeks`/`WinterWeeks` now means **"follow the type"** — the plant's effective
+schedule falls back to its type's suggested value (see `get_plant`'s `typeValue` on each schedule
+field) rather than having no schedule at all; `null` on `wateringNotes`/`fertilizingNotes` still just
+clears the note.
+
+The watering fields only take effect while the plant's watering is on a schedule — a reservoir/hydro
+plant has no cycle for them to configure, so they're silently ignored for one. The fertilizing-cycle
+fields are likewise ignored while the plant fertilizes with every watering rather than on its own
+cycle. Passing `wateringMode`/`fertilizingMode` in the **same call** as the fields they gate checks
+against the *new* mode, not the current one — so switching a plant to `"reservoir"` while also
+setting a watering cycle just drops that cycle rather than saving it. `careMode` (a legacy mirror of
+`wateringMode`) updates itself; it isn't a field you set. This is also the tool that actually fixes a
+`wateringCycleMismatch` recommendation — that recommendation's own text says "edit the plant," and
+the mode causing the mismatch lives here.
+
+`update_plant`'s `plantTypeId` points the plant at a **global** catalog type (from
+`list_plant_types`/`search_plant_types`; a `MERGED` id transparently resolves to its survivor); `null`
+makes the plant "unidentified". `nickname` is required whenever the plant's state *after* this edit
+has no type — set together with `plantTypeId: null`, or already unidentified and not gaining a type
+in this same call.
 
 `update_plant`'s `locationId`/`soilId`/`fertilizerId` must be one of **your own** catalog ids (from
 `list_locations`/`list_soils`/`list_fertilizers`) — an unowned or unknown id is rejected.
@@ -285,13 +408,18 @@ don't exist yet, `propagate_plant` creates them *and* sets the link in one call.
 
 | Tool | Endpoint | Arguments |
 |---|---|---|
-| `create_plant` | `POST /api/v1/plants` | `plantTypeId` **(required)**, `reference` (default `false`), `parentPlantId` |
+| `create_plant` | `POST /api/v1/plants` | `plantTypeId` (optional — omit/`null` for unidentified), `nickname` (required when unidentified), `reference` (default `false`), `parentPlantId` |
 | `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_reference` | `PATCH /api/v1/plants/:id/reference` | `plantId`, `reference` (boolean) **(both required)** |
 
-`create_plant` needs an **existing** `plantTypeId` from `list_plant_types` — creating a plant *type*
-is still a UI action, so if the species isn't in your catalog yet, that step happens in the app.
+`create_plant`'s `plantTypeId` is now **optional**: pass an existing global type id (from
+`list_plant_types`/`search_plant_types`) when the species is known, or omit it (or pass `null`) to
+add an "unidentified" plant — `nickname` is then required, matching the app's plant form. Creating a
+plant *type* is still a UI action, so if the species isn't in the catalog yet, that step happens in
+the app; an unidentified plant can always be identified there later.
 
 `reference: true` creates an `EXTERNAL` plant: somebody else's, recorded only so lineage has a real
 node to point at. It gets no acquisition date, no care schedule, and no place in collection stats —
@@ -307,6 +435,21 @@ call. All sources must be `LIVING`, and `survivorPlantId` must not also appear i
 Unmerging leaves the survivor in place. If the merge created it via `createNewFrom` and you no
 longer want it, deleting that plant is a UI action.
 
+`set_plant_status` is deliberately narrower than the app's own edit-form status dropdown:
+`GIFTED`/`SOLD`/`TRADED` need a recipient (out of scope — see **What this server deliberately cannot
+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`.
+
+`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
+`LIVING`, `false` requires `EXTERNAL`. Reversible either direction; nothing on the plant is lost.
+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: true` covers making a *new* reference plant; this is
+for converting one already in the collection.
+
 ### Health entries
 
 | Tool | Endpoint | Arguments |
@@ -333,6 +476,63 @@ Dismissible `type` values: `wateringOftenLate`, `fertilizingOftenLate`, `noFerti
 `recentlyRepottedAvoidFertilizer`, `noRecentPhoto`. `wateringCycleMismatch` is **not** dismissible —
 it is a configuration contradiction, fixed by editing the plant rather than hidden.
 
+### Wishlist
+
+| Tool | Endpoint | Arguments |
+|---|---|---|
+| `add_to_wishlist` | `POST /api/v1/wishlist` | `plantTypeId` or `name` — at least one required |
+| `add_wishlist_note` | `POST /api/v1/wishlist/:id/notes` | `wishId` **(required)**, `text` **(required,** 1–500 chars**)** |
+| `remove_from_wishlist` | `DELETE /api/v1/wishlist/:id` | `wishId` **(required)** |
+
+`add_to_wishlist` never creates a second wish for a type the caller already has — it returns the
+existing one instead (`duplicate: true`), rather than erroring or silently doubling it up.
+
+### Watched types
+
+| Tool | Endpoint | Arguments |
+|---|---|---|
+| `watch_type` | `POST /api/v1/plant-type-watches` | `plantTypeId` **(required)** |
+| `unwatch_type` | `DELETE /api/v1/plant-type-watches/:plantTypeId` | `plantTypeId` **(required)** |
+
+`watch_type` never creates a second watch for a type the caller already watches — it returns the
+existing one instead (`duplicate: true`), the same convention as `add_to_wishlist`. Unlike the
+in-app eye toggle (which flips whatever the current state is), these are explicit add/remove calls —
+a tool call should never guess the caller's current state.
+
+### Notifications
+
+| Tool | Endpoint | Arguments |
+|---|---|---|
+| `mark_notifications_read` | `POST /api/v1/notifications/mark-read` | none |
+
+Marks every currently-unread notification read — the same as the notification centre's "Alles als
+gelesen markieren" action. There is no per-notification mark-read tool; the app has no such action to
+mirror (opening the page already marks everything read).
+
+### Catalogs
+
+| Tool | Endpoint | Arguments |
+|---|---|---|
+| `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) |
+| `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` |
+
+`create_location`/`create_soil`/`create_fertilizer`/`create_pot` each mirror the app's own "create
+inline" picker on the plant form — same validation, same duplicate-name handling (a name already
+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.
+
+`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
+**server-side**: if a likely duplicate is found, nothing is created and the response is
+`{ created: false, duplicates }` instead of an error — review the candidates (or resolve the plant
+onto an existing type with `update_plant`/`create_plant`) and either use one of those ids, or call
+again with `confirmDespiteDuplicates: true` to create anyway. Only the dialog's "Steckbrief" subset
+of catalog fields is settable via `values`; a fuller edit needs the UI or an admin key.
+
 ### Deleting events
 
 | Tool | Endpoint | Arguments |
@@ -340,7 +540,9 @@ it is a configuration contradiction, fixed by editing the plant rather than hidd
 | `delete_watering_event` | `DELETE /api/v1/plants/:id/watering-events/:eventId` | `plantId`, `eventId` — both **required** |
 | `delete_fertilization_event` | `DELETE /api/v1/plants/:id/fertilization-events/:eventId` | `plantId`, `eventId` — both **required** |
 
-**These are the only destructive tools in this server, and neither can be undone.** Take `eventId`
+**These are the only tools that delete collection history, and neither can be undone.** (`remove_from_wishlist`
+also deletes a row, but a wish carries no history — see **What this server deliberately cannot do**
+above.) Take `eventId`
 from `list_watering_events` / `list_fertilization_events` / `list_care_events`. For a reservoir or
 hydro plant, `delete_watering_event` deletes its refill/top-up event instead — the same routing
 `record_watering` uses on the write side.
@@ -362,22 +564,23 @@ the response, not just the HTTP status.
 
 ## Admin tools (admin-scoped keys only)
 
-**17 tools** over the shared, community-maintained global plant type catalog — every plant's
-species/cultivar entry, one catalog for the whole app rather than per-user. They need the `admin`
-scope (see **Permissions & scopes** above), so a non-admin key's session never even sees them: the
-server calls `whoami` once at startup and only registers these tools when the response's `scopes`
-includes `admin`.
+**18 tools** — 17 over the shared, community-maintained global plant type catalog (every plant's
+species/cultivar entry, one catalog for the whole app rather than per-user) plus one over the
+instance's own operational status. They need the `admin` scope (see **Permissions & scopes** above),
+so a non-admin key's session never even sees them: the server calls `whoami` once at startup and only
+registers these tools when the response's `scopes` includes `admin`.
 
-### Read-only (6)
+### Read-only (7)
 
 | Tool | Endpoint | Arguments |
 |---|---|---|
-| `admin_list_plant_types` | `GET /api/v1/admin/plant-types` | all optional: `status` (`UNVERIFIED`\|`VERIFIED`\|`MERGED`, defaults to every non-MERGED type), `search` (names + botanical), `genus`, `parentId` (a species-level type's cultivar children), `missingField` (a field key from `admin_get_plant_type_field_schema` — only types missing it), `hasOpenProposals`, `limit` (1–200), `offset` |
-| `admin_get_plant_type` | `GET /api/v1/admin/plant-types/:id` | `id` **(required)** — full detail: identity/status, parent/children, names, own/inherited/effective values, plant/user counts, open proposals, open duplicate candidates, image count, recent change log |
+| `admin_list_plant_types` | `GET /api/v1/admin/plant-types` | all optional: `status` (`UNVERIFIED`\|`VERIFIED`\|`MERGED`, defaults to every live type — excludes both `MERGED` and `REJECTED`; a `REJECTED` type has no filter value of its own here yet), `search` (names + botanical), `genus`, `parentId` (a species-level type's cultivar children), `missingField` (a field key from `admin_get_plant_type_field_schema` — only types missing it), `hasOpenProposals`, `limit` (1–200), `offset` |
+| `admin_get_plant_type` | `GET /api/v1/admin/plant-types/:id` | `id` **(required)** — full detail: identity/status (including `REJECTED`, for an admin-rejected user-created type — see `mergedIntoId`), parent/children, names, own/inherited/effective values, plant/user counts, open proposals, open duplicate candidates, image count, recent change log |
 | `admin_get_plant_type_field_schema` | `GET /api/v1/admin/plant-types/fields` | none — every guidance field's kind, bounds, allowed values, and what a scale value or unit means |
 | `admin_list_duplicate_candidates` | `GET /api/v1/admin/plant-types/duplicates` | `status` (`OPEN`\|`DISMISSED`\|`MERGED`, defaults to `OPEN`), `limit` (1–200), `offset` |
 | `admin_list_plant_type_proposals` | `GET /api/v1/admin/plant-types/proposals` | `status` (defaults to `PENDING`), `origin` (`user`\|`migration`), `typeId`, `limit` (1–200), `offset` |
 | `admin_preview_plant_type_merge` | `GET /api/v1/admin/plant-types/merge-preview` | `sourceId`, `targetId` **(both required)** — the per-field carry-over plan and merge guard for both directions |
+| `admin_get_dashboard_status` | `GET /api/v1/admin/dashboard` | none — review-queue counts + oldest-item age, catalog health, weekly activity, and operational facts (counts only, never a secret) |
 
 `admin_list_plant_types` returns compact rows only (no full field values) — call `admin_get_plant_type`
 for one type's complete fact sheet. Its `search` is fuzzy, the same matcher the admin catalog list
@@ -393,6 +596,13 @@ write) can always be checked against real bounds/enum values first.
 changed field `stale` when the type's value has moved on since the proposal was filed — the exact
 check a human reviewer's accept button re-runs, so an assistant sees the same warning.
 
+`admin_get_dashboard_status` is the one admin tool that isn't about the catalog — it returns the same
+aggregate the app's own `/admin` dashboard shows, for "what needs me, and is anything wrong" in one
+call instead of several. Some values are legitimately absent rather than zero: a review-queue item's
+`age` comes back `{ kind: "unknown" }` when its type has no creation timestamp to measure from
+(pending user registrations), and `operations.appliedMigrationsCount` can be `null` when that guarded
+read failed — never a fabricated number either way.
+
 ### Write (11)
 
 Every description starts with `ADMIN WRITE:`, and **every one of these requires a non-empty `note`**
@@ -490,6 +700,34 @@ can act on them or explain them to you:
 
 A non-JSON body is passed through as raw text rather than being swallowed.
 
+## Breaking changes in 2.0.0
+
+Plant identity moved from a per-user catalog to a shared, community-maintained one. If your client
+(or a cached tool call) held onto a `plantTypeId` from before this release, it needs re-resolving —
+the id spaces are unrelated. The full rationale is in the app's `docs/mcp-server.md`; the mechanical
+changes:
+
+- **`plantTypeId` means a global catalog id everywhere it appears** (`list_plants`, `get_plant`,
+  `create_plant`, `update_plant`) — not the old per-user type id. Re-resolve any id you cached before
+  this release via `list_plant_types`/`search_plant_types`.
+- **`list_plant_types` now serves the global catalog**, not the caller's own types — every caller
+  sees the same rows now, differing only in `viewerPlantsCount`.
+- **New: `search_plant_types` and `get_plant_type`** — see **Catalogs** above.
+- **`plantTypeId` is now optional on `create_plant` and `update_plant`** — omit it (or pass `null`)
+  for an "unidentified" plant. `nickname` becomes required whenever the plant ends up with no type.
+- **`get_plant`'s `plantType` field is replaced by `type`** — see its row above for the new shape
+  (`plantTypeId`, `nickname`, `displayName`, `botanicalName`, `typeStatus`, `isUnidentified`).
+  `list_plants` rows changed the same way.
+- **`get_plant` gained `typeFacts`** (the type's effective light/water/feeding need, toxicity,
+  climate, growth, substrate/propagation, family/native region).
+- **`get_plant`'s six schedule fields are no longer raw values** — each is now
+  `{ value, source, typeValue }`. A consumer reading e.g. `plant.wateringFrequencySummerDays` as a
+  number directly will break; read `.value` instead.
+- **`update_plant_care` no longer accepts `sunRequirement`/`waterRequirement`** — both are type-only
+  facts now.
+- **`null` on `update_plant_care`'s watering/fertilizing-cycle fields now means "follow the type"**,
+  not "no schedule" — see that tool's row above.
+
 ## Versioning
 
 Semver against the **tool surface**, which is this package's public API:

package/dist/index.js

@@ -131,16 +131,16 @@ server.tool("list_plants", "List the user's plants, with optional filters. Retur
         .describe("Filter by plant status. EXTERNAL is a reference plant: somebody else's plant, recorded only as an anchor for propagation lineage — never cared for and not part of the collection's totals."),
     lifecycle: z.enum(["PROPAGATING", "ESTABLISHED"]).optional().describe("Filter by lifecycle stage."),
     locationId: z.number().int().optional().describe("Filter by location id."),
-    plantTypeId: z.number().int().optional().describe("Filter by plant type (species) id."),
+    plantTypeId: z.number().int().optional().describe("Filter by global plant type id, from list_plant_types/search_plant_types/get_plant."),
     soilId: z.number().int().optional().describe("Filter by soil id."),
     fertilizerId: z.number().int().optional().describe("Filter by fertilizer id."),
     tag: z.string().optional().describe("Filter by exact tag (case-sensitive)."),
-    search: z.string().optional().describe("Free-text search over plant type name / notes."),
+    search: z.string().optional().describe("Free-text search over the plant's nickname, its type's names, and notes."),
     limit: z.number().int().min(1).max(200).optional().describe("Max results (pagination)."),
     offset: z.number().int().min(0).optional().describe("Result offset (pagination)."),
-    sort: z.string().optional().describe("Sort key, e.g. 'name', 'createdAt', 'updatedAt'."),
+    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: catalogs (type, location, soil, fertilizer), care config, and recent event summaries.", { 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.", { 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."),
@@ -152,6 +152,7 @@ server.tool("list_fertilization_events", "List fertilization events for a plant,
 server.tool("list_care_events", "List the combined care timeline for a plant (watering, fertilization, refill, hydro, potting, snoozes), each tagged with a kind, most recent first.", eventArgs, async ({ id, ...q }) => apiGet(`/api/v1/plants/${id}/events`, q));
 server.tool("list_photos", "List photo metadata for a plant (urls, takenAt), most recent first.", eventArgs, async ({ id, ...q }) => apiGet(`/api/v1/plants/${id}/photos`, q));
 server.tool("list_health_entries", "List health and AI-analysis entries for a plant, most recent first.", eventArgs, async ({ id, ...q }) => apiGet(`/api/v1/plants/${id}/health`, q));
+server.tool("list_diagnoses", "List past guided problem-diagnosis runs for a plant ('Problem eingrenzen' in the app), most recent first: the symptom, every question with the answer given, the ranked possible causes, the chosen action, and the AI second opinion if one was requested. Resolved to plain English text. Read-only — the guided flow itself is a UI-only experience; use add_health_entry to log an observation directly instead.", eventArgs, async ({ id, ...q }) => apiGet(`/api/v1/plants/${id}/diagnoses`, q));
 // --- Care schedule (calendar) ----------------------------------------------
 /**
  * Derived schedule state, computed server-side from the same helpers the app's
@@ -206,6 +207,7 @@ server.tool("collection_stats", "Counts and totals across the whole collection:
 server.tool("sitter_briefing", "Printable care sheet for the caller's current or next sitter-covered vacation: per-plant sitter instructions, watering notes, watering cycle and next-due state, plus the day-by-day watering schedule for the trip. Returns { hasVacation: false } when there is no upcoming or running vacation in 'sitter' mode. Read-only — does not create or modify a vacation.", {
     locationId: z.number().int().optional().describe("Only include plants in this location (id from list_locations). Omit for every plant on the vacation."),
 }, async (args) => apiGet("/api/v1/vacation/sitter-briefing", args));
+server.tool("get_vacation_status", "Whether the caller has a current or upcoming vacation, in either mode ('sitter' or 'shift') — unlike sitter_briefing, which only ever reports a 'sitter'-mode one. Returns { hasVacation: false } when none is running or scheduled, otherwise the vacation's id, mode, date range, whether it has started yet (isActive/isUpcoming), and how many plants it covers. Read-only status only — for a sitter-mode vacation's full per-plant detail and schedule, use sitter_briefing.", async () => apiGet("/api/v1/vacation/status"));
 // --- Care logging (writes) --------------------------------------------------
 /**
  * Mutating tools. These require an API key with the `write` scope; a read-only
@@ -234,24 +236,56 @@ 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("update_plant_care", "WRITE: edit a plant's care schedule — watering mode, days/labels, sun and water requirement, fertilizing mode, cycles and percent, and the watering/fertilizing notes. Omitted fields keep their current value; null clears a notes/label field. Watering fields other than sunRequirement 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. Use this (not update_plant) to fix a 'wateringCycleMismatch' recommendation where the mode itself is wrong. 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. 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."),
+    soilId: z.number().int().positive().optional().describe("Soil mix id, from list_soils."),
+    pottedAt: optionalPlantDate("Defaults to today, or to the plant's acquiredAt for its first-ever potting event."),
+    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."),
+}, 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."),
+    fertilizerId: z.number().int().positive().optional().describe("Override fertilizer; defaults to the plant's own."),
+    fertilizerPercent: z.number().int().min(0).max(1000).optional().describe("Strength as a percentage of the base dose; defaults to the plant's own."),
+    refilledAt: optionalPlantDate(""),
+}, async ({ plantId, ...body }) => apiSend("POST", `/api/v1/plants/${plantId}/refill`, body));
+server.tool("record_hydro_event", "WRITE: log a hydro-culture event for a hydro-mode plant — a water top-up (default) or a full solution change. waterLevel (0-100) and the fertilizer fields are optional for either kind. Requires a write-scoped API key.", {
+    plantId: z.number().int().positive().describe("Plant id."),
+    kind: z.enum(["topup", "change"]).optional().describe("'topup' (default) or 'change' (full solution change)."),
+    waterLevel: z.number().int().min(0).max(100).optional().describe("Reservoir fill level as a percentage."),
+    fertilizerId: z.number().int().positive().optional().describe("Override fertilizer; defaults to the plant's own."),
+    fertilizerPercent: z.number().int().min(0).max(1000).optional().describe("Strength as a percentage of the base dose; defaults to the plant's own."),
+    recordedAt: optionalPlantDate(""),
+    notes: z.string().max(2000).optional().describe("Free-text notes."),
+}, async ({ plantId, ...body }) => apiSend("POST", `/api/v1/plants/${plantId}/hydro`, body));
+server.tool("snooze_care", "WRITE: postpone a plant's next watering or fertilizing due date by a fixed duration — the same snooze picker the care hub offers. originalDueAt is the due date being pushed out (the nextDue value from list_due_care/get_care_calendar for that plant/careType), not today's date. durationDays must be one of the app's presets: 1, 3, 7, or 14. Requires a write-scoped API key.", {
+    plantId: z.number().int().positive().describe("Plant id."),
+    careType: z.enum(["water", "fert"]).describe("Which schedule to postpone."),
+    durationDays: z.union([z.literal(1), z.literal(3), z.literal(7), z.literal(14)]).describe("Snooze duration in days — one of the app's presets."),
+    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.", {
     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."),
-    sunRequirement: z.number().int().min(1).max(4).optional().describe("1 (low light) to 4 (full sun)."),
-    waterRequirement: z.number().int().min(1).max(3).optional().describe("1 (low) to 3 (high). Ignored unless watering is scheduled."),
-    wateringFrequencySummer: z.string().max(50).nullable().optional().describe("Free-text summer watering label, e.g. 'twice a week'. Ignored unless watering is scheduled."),
-    wateringFrequencySummerDays: z.number().int().min(1).max(365).optional().describe("Summer watering interval in days. Ignored unless watering is scheduled."),
-    wateringFrequencyWinter: z.string().max(50).nullable().optional().describe("Free-text winter watering label. Ignored unless watering is scheduled."),
-    wateringFrequencyWinterDays: z.number().int().min(1).max(365).optional().describe("Winter watering interval in days. Ignored unless watering is scheduled."),
+    wateringFrequencySummer: z.string().max(50).nullable().optional().describe("Free-text summer watering label, e.g. 'twice a week'. null follows the type's guidance. Ignored unless watering is scheduled."),
+    wateringFrequencySummerDays: z.number().int().min(1).max(365).nullable().optional().describe("Summer watering interval in days. null follows the type's suggested days. Ignored unless watering is scheduled."),
+    wateringFrequencyWinter: z.string().max(50).nullable().optional().describe("Free-text winter watering label. null follows the type's guidance. Ignored unless watering is scheduled."),
+    wateringFrequencyWinterDays: z.number().int().min(1).max(365).nullable().optional().describe("Winter watering interval in days. null follows the type's suggested days. Ignored unless watering is scheduled."),
     wateringNotes: z.string().max(500).nullable().optional().describe("Free-text watering notes. Ignored unless watering is scheduled."),
-    fertilizingCycleSummerWeeks: z.number().int().min(0).max(52).optional().describe("Summer fertilizing interval in weeks. Ignored while fertilizing is 'with every watering'."),
-    fertilizingCycleWinterWeeks: z.number().int().min(0).max(52).optional().describe("Winter fertilizing interval in weeks. Ignored while fertilizing is 'with every watering'."),
+    fertilizingCycleSummerWeeks: z.number().int().min(0).max(52).nullable().optional().describe("Summer fertilizing interval in weeks. null follows the type's suggested weeks. Ignored while fertilizing is 'with every watering'."),
+    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."),
 }, async ({ plantId, ...body }) => apiSend("PATCH", `/api/v1/plants/${plantId}/care`, body));
-server.tool("update_plant", "WRITE: edit a plant's 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. Requires a write-scoped API key.", {
+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."),
+    plantTypeId: z.number().int().positive().nullable().optional().describe("New global plant type id, from list_plant_types/search_plant_types/get_plant. A MERGED id transparently resolves to its survivor. null makes the plant unidentified — nickname is then required."),
+    nickname: z.string().max(100).nullable().optional().describe("The plant's own name, shown instead of the type's name when set. Required when the plant has (or is becoming) unidentified."),
     locationId: z.number().int().positive().nullable().optional().describe("New location id, from list_locations. null unassigns it."),
     soilId: z.number().int().positive().nullable().optional().describe("New soil id, from list_soils. null unassigns it."),
     fertilizerId: z.number().int().positive().nullable().optional().describe("New fertilizer id, from list_fertilizers. null unassigns it."),
@@ -308,8 +342,9 @@ server.tool("delete_fertilization_event", "WRITE: delete a fertilization event f
     eventId: z.number().int().positive().describe("Event id, from list_fertilization_events or list_care_events."),
 }, async ({ plantId, eventId }) => apiSend("DELETE", `/api/v1/plants/${plantId}/fertilization-events/${eventId}`));
 // --- Plant lifecycle (writes) ------------------------------------------------
-server.tool("create_plant", "WRITE: add a new plant to the collection. plantTypeId is required and must be an existing type — call list_plant_types first and pick the matching one; creating a new plant type is not possible here and stays a UI action. Set reference: true to record somebody else's plant (status EXTERNAL): it is not one of the user's own plants, gets no acquisition date and no care schedule, and is excluded from collection stats — its purpose is to be a real node that propagation lineage can point at. Requires a write-scoped API key.", {
-    plantTypeId: z.number().int().positive().describe("Plant type id, from list_plant_types."),
+server.tool("create_plant", "WRITE: add a new plant to the collection. plantTypeId is now optional (omit it, or pass null, to create an 'unidentified' plant) — call list_plant_types/search_plant_types first and pick the matching one when the species is known; creating a new plant type is not possible here and stays a UI action. nickname is required whenever plantTypeId is omitted/null, matching the app's plant form. Set reference: true to record somebody else's plant (status EXTERNAL): it is not one of the user's own plants, gets no acquisition date and no care schedule, and is excluded from collection stats — its purpose is to be a real node that propagation lineage can point at. Requires a write-scoped API key.", {
+    plantTypeId: z.number().int().positive().nullable().optional().describe("Global plant type id, from list_plant_types/search_plant_types. Omit (or pass null) for an unidentified plant — a MERGED id transparently resolves to its survivor."),
+    nickname: z.string().max(100).optional().describe("The plant's own name. Required when plantTypeId is omitted or null."),
     reference: z.boolean().optional().describe("true creates an EXTERNAL reference plant (somebody else's, a lineage anchor only). Defaults to false: a LIVING plant of the user's own."),
     parentPlantId: z.number().int().positive().optional().describe("Optional: the plant this one was propagated from."),
 }, async (body) => apiSend("POST", "/api/v1/plants", { ...body }));
@@ -325,11 +360,135 @@ 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.", {
+    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."),
+}, 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."),
+    reference: z.boolean().describe("true: mark as a reference plant (must be LIVING now). false: turn a reference plant back into the caller's own (must be EXTERNAL now)."),
+}, async ({ plantId, reference }) => apiSend("PATCH", `/api/v1/plants/${plantId}/reference`, { reference }));
+// --- Wishlist ----------------------------------------------------------
+/**
+ * The caller's personal wishlist (R2-15) — plants they want but don't own
+ * yet, either a global catalog type (`plantTypeId`) or a free-text name
+ * fallback for a species not in the catalog. Unlike sales/trades, wishes
+ * are never exposed-but-excluded: they're the caller's own data, about
+ * their own collection, so there's no second-person consent concern.
+ */
+server.tool("list_wishlist", "List the caller's wishlist: each wish's plant type (when set) with its display/botanical name, or a free-text name fallback, plus notes and how many LIVING plants of that type the caller already owns.", async () => apiGet("/api/v1/wishlist"));
+server.tool("add_to_wishlist", "WRITE: add a wish — a global catalog type (plantTypeId, from list_plant_types/search results) or a free-text name for a species not in the catalog yet. At least one is required. Never creates a second wish for a type the caller already has — returns the existing one instead (duplicate: true). Requires a write-scoped API key.", {
+    plantTypeId: z.number().int().positive().optional().describe("An existing global plant type id."),
+    name: z.string().max(100).optional().describe("Free-text name fallback, for a species not yet in the catalog."),
+}, async ({ plantTypeId, name }) => apiSend("POST", "/api/v1/wishlist", { plantTypeId, name }));
+server.tool("add_wishlist_note", "WRITE: add a dated note to a wish — price, where to get it, a shop link, etc. Requires a write-scoped API key.", {
+    wishId: z.number().int().positive().describe("Wish id, from list_wishlist."),
+    text: z.string().min(1).max(500).describe("The note text."),
+}, async ({ wishId, text }) => apiSend("POST", `/api/v1/wishlist/${wishId}/notes`, { text }));
+server.tool("remove_from_wishlist", "WRITE: remove a wish (e.g. once it's been fulfilled by a new plant). Requires a write-scoped API key.", {
+    wishId: z.number().int().positive().describe("Wish id, from list_wishlist."),
+}, async ({ wishId }) => apiSend("DELETE", `/api/v1/wishlist/${wishId}`));
+// --- Watched plant types -------------------------------------------------
+/**
+ * The caller's "watch a type" subscriptions — the eye toggle on a catalog
+ * row or type page. A watched type notifies its watcher (in-app, via the
+ * Neuigkeiten centre — see list_notifications below) whenever an admin
+ * edits its fields, identity or names, verifies it, merges it into another
+ * type, or a new photo is approved for it.
+ */
+server.tool("list_watched_types", "List the caller's watched plant types: each watch's type id, display/botanical name and status.", async () => apiGet("/api/v1/plant-type-watches"));
+server.tool("watch_type", "WRITE: watch a global catalog type (plantTypeId, from list_plant_types/search results) — the caller gets notified in-app when its fields, identity, names, verification status or photos change. Never creates a second watch for a type already watched — returns the existing one instead (duplicate: true). Requires a write-scoped API key.", {
+    plantTypeId: z.number().int().positive().describe("An existing global plant type id."),
+}, async ({ plantTypeId }) => apiSend("POST", "/api/v1/plant-type-watches", { plantTypeId }));
+server.tool("unwatch_type", "WRITE: stop watching a plant type. Requires a write-scoped API key.", {
+    plantTypeId: z.number().int().positive().describe("The watched type's id, from list_watched_types."),
+}, async ({ plantTypeId }) => apiSend("DELETE", `/api/v1/plant-type-watches/${plantTypeId}`));
+// --- Notifications -----------------------------------------------------------
+/**
+ * The in-app notification centre (`/notifications`): catalog decisions on a
+ * watched type, a watched/created type's photo or proposal outcome, and a
+ * collection share — one durable, always-on channel alongside push/email.
+ * Sale/trade notifications are always excluded here, the same permanent
+ * exclusion `list_recent_activity` applies — each names a second person who
+ * never consented to the owner's API key.
+ */
+server.tool("list_notifications", "List the caller's notifications, newest first, cursor-paginated. Each item has a messageKey and values (interpolation data, not pre-rendered text — the exact sentence depends on locale) plus an href into the app and, when the event has one, the actor who triggered it. Sale/trade notifications are never included. Pass the previous call's nextCursor to load the next page.", {
+    cursor: z.number().int().optional().describe("Pass the previous call's nextCursor to continue; omit for the first page."),
+}, async ({ cursor }) => apiGet("/api/v1/notifications", { cursor }));
+server.tool("mark_notifications_read", "WRITE: mark every currently-unread notification read — the same as the notification centre's 'Alles als gelesen markieren' action. There is no per-notification mark-read tool; the app itself has none to mirror (opening the page already marks everything read). Requires a write-scoped API key.", async () => apiSend("POST", "/api/v1/notifications/mark-read"));
 // --- Catalogs (for resolving filter ids) -----------------------------------
 server.tool("list_locations", "List the user's locations.", async () => apiGet("/api/v1/locations"));
-server.tool("list_plant_types", "List the user's plant types (species taxonomy).", async () => apiGet("/api/v1/plant-types"));
+/**
+ * R2-12: the global plant type catalog, shared by every user — not a
+ * per-user list any more. `list_plant_types` and `search_plant_types` are
+ * deliberately the same underlying endpoint/reader (`GET /api/v1/plant-types`
+ * — see `docs/mcp-server.md`'s "Catalog reads" section): browsing and
+ * searching are the same fuzzy-filtered, paged list, just with `query`
+ * required for one and optional for the other, so a model reaching for
+ * either gets the same result shape and paging behavior.
+ */
+const publicPlantTypeListArgs = {
+    status: z.enum(["UNVERIFIED", "VERIFIED"]).optional().describe("Filter by review status. Defaults to every live type (both)."),
+    inMyCollection: z.boolean().optional().describe("true: only types the caller has at least one LIVING plant of."),
+    limit: z.number().int().min(1).max(200).optional().describe("Max results (pagination)."),
+    offset: z.number().int().min(0).optional().describe("Result offset (pagination)."),
+};
+server.tool("list_plant_types", "Browse the shared global plant type catalog — every plant's species/cultivar entry, one catalog for the whole app. Pass query to search by name/botanical; omit it to just browse (optionally filtered by status/inMyCollection). Compact rows only — no full field values or facts; use get_plant_type for one type's fact sheet. A MERGED type never appears here — see get_plant_type for how an id that was since merged resolves.", { query: z.string().optional().describe("Fuzzy search over names (all locales) and the botanical name."), ...publicPlantTypeListArgs }, async (args) => apiGet("/api/v1/plant-types", { ...args, inMyCollection: args.inMyCollection?.toString() }));
+server.tool("search_plant_types", "Fuzzy search the shared global plant type catalog by name (all locales) or botanical name — the search-first counterpart to list_plant_types (same endpoint, query required here). Use this when the caller named a species/plant and you need its id, e.g. before create_plant or update_plant.", { query: z.string().min(1).describe("Search text — a common name in any language, or a botanical name."), ...publicPlantTypeListArgs }, async (args) => apiGet("/api/v1/plant-types", { ...args, inMyCollection: args.inMyCollection?.toString() }));
+server.tool("get_plant_type", "Get one global plant type's fact sheet: identity and status, names by locale, parent/cultivar children, effective catalog facts (light, water, feeding need, toxicity, climate, growth, substrate/propagation, family/native region) with each field's source ('own' vs. 'inherited' from an ancestor), approved image URLs, and how many of the caller's own LIVING plants use it. A MERGED id transparently resolves to its survivor (mergedIntoId is still reported) rather than returning a redirect stub — unlike the admin equivalent.", { id: z.number().int().describe("Global plant type id, from list_plant_types/search_plant_types/get_plant.") }, async ({ id }) => apiGet(`/api/v1/plant-types/${id}`));
+server.tool("create_plant_type", "WRITE: add a species/cultivar the shared global catalog is missing — the same capability as the plant-type picker's 'Neue Art anlegen' dialog. Always lands UNVERIFIED. At least one of genus or commonName is required. Only a small 'Steckbrief' subset of catalog fields is settable here (sunRequirement and waterRequirement are required within it; suggestedWateringDaysSummer/Winter, toxicToPets, difficulty are optional) — a fuller edit needs the UI or an admin key. Unlike the UI dialog (which warns about likely duplicates client-side before you even submit), this checks server-side: if a likely duplicate is found, nothing is created and the response is { created: false, duplicates } instead — review them (or resolve the plant onto an existing type with update_plant/create_plant) and either use one of those ids, or call again with confirmDespiteDuplicates: true to create anyway. Requires a write-scoped API key.", {
+    genus: z.string().max(100).optional().describe("Genus. Required together with species/cultivar identity, or provide commonName instead."),
+    species: z.string().max(100).optional().describe("Species epithet."),
+    cultivar: z.string().max(100).optional().describe("Cultivar name."),
+    commonName: z.string().max(100).optional().describe("A common name, in the caller's own locale. Required if genus is omitted."),
+    values: z
+        .object({
+        sunRequirement: z.union([z.number(), z.string(), z.boolean(), z.array(z.string())]).nullable().optional(),
+        waterRequirement: z.union([z.number(), z.string(), z.boolean(), z.array(z.string())]).nullable().optional(),
+        suggestedWateringDaysSummer: z.union([z.number(), z.string(), z.boolean(), z.array(z.string())]).nullable().optional(),
+        suggestedWateringDaysWinter: z.union([z.number(), z.string(), z.boolean(), z.array(z.string())]).nullable().optional(),
+        toxicToPets: z.union([z.number(), z.string(), z.boolean(), z.array(z.string())]).nullable().optional(),
+        difficulty: z.union([z.number(), z.string(), z.boolean(), z.array(z.string())]).nullable().optional(),
+    })
+        .describe("The 'Steckbrief' fields — sunRequirement and waterRequirement are required (use admin_get_plant_type_field_schema's field definitions for exact value shapes/bounds); the rest are optional."),
+    note: z.string().max(500).optional().describe("Optional context for the catalog change log. Defaults to a generic 'created via MCP' note."),
+    confirmDespiteDuplicates: z.boolean().optional().describe("Set true to create anyway after reviewing the duplicates a prior call returned."),
+}, async (body) => apiSend("POST", "/api/v1/plant-types", body));
+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 }));
 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."),
+    notes: z.string().max(2000).optional().describe("Free-text notes."),
+    items: z
+        .array(z.object({ componentName: z.string().min(1).max(100), parts: z.number().int().min(1).max(100) }))
+        .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("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."),
+    npk: z.string().max(30).optional().describe("NPK ratio label, e.g. '7-3-6'."),
+    baseDosePerLiterMl: z.number().min(0).max(100).optional().describe("Base dose in ml per liter of water."),
+}, async ({ name, npk, baseDosePerLiterMl }) => apiSend("POST", "/api/v1/fertilizers", { name, npk, baseDosePerLiterMl }));
+server.tool("list_pots", "List the caller's own pots plus the shared default pots, defaults first. Each includes its reference links and any recorded sizes (addressed by id from record_repotting-style potSize fields once that tool exists).", async () => apiGet("/api/v1/pots"));
+server.tool("create_pot", "WRITE: create a pot, optionally with reference links (a shop or care-guide URL). Pot sizes have no create tool yet — add one from the app after creating the pot. Requires a write-scoped API key.", {
+    name: z.string().min(1).max(100).describe("Pot name."),
+    material: z.string().max(50).optional().describe("Material, e.g. 'Terracotta'."),
+    isSelfWatering: z.boolean().optional().describe("Whether the pot is self-watering."),
+    notes: z.string().max(2000).optional().describe("Free-text notes."),
+    links: z
+        .array(z.object({ url: z.string().max(2000), label: z.string().max(80).optional() }))
+        .optional()
+        .describe("Reference links, e.g. a shop listing. Order follows the array."),
+}, async ({ name, material, isSelfWatering, notes, links }) => apiSend("POST", "/api/v1/pots", { name, material, isSelfWatering, notes, links }));
 // --- Admin: global plant type catalog (admin-scoped keys only) -------------
 /**
  * Tools over the shared, community-maintained plant type catalog — finding
@@ -454,6 +613,7 @@ function registerAdminTools() {
         note: z.string().min(1).describe("Required, but not persisted — see the tool description."),
     }, async ({ id, note }) => apiSend("POST", `/api/v1/admin/plant-types/duplicates/${id}/dismiss`, { note }));
     server.tool("admin_rescan_duplicate_candidates", "ADMIN WRITE: re-run duplicate detection against the whole live catalog and reconcile the duplicate-candidate queue — the same 'Rescan' button the admin Duplicates tab has, for when catalog edits (new types, merges, name or identity changes) since the last migration run mean the queue no longer reflects what a fresh scan would produce. A previously dismissed or already-merged pair never comes back. No note needed: this only rebuilds the queue, there is no reviewable decision to leave a reason for. Returns how many candidates were added, updated, and removed. Requires an admin-scoped API key.", async () => apiSend("POST", "/api/v1/admin/plant-types/duplicates/rescan", {}));
+    server.tool("admin_get_dashboard_status", "ADMIN: the instance's operational status in one call — the same aggregate the app's own /admin dashboard shows. Four groups: reviewQueue (pending proposals, pending submitted images, open duplicate candidates, unverified types, and pending user registrations — each with its count and the age in days of its oldest item), catalogHealth (verified/unverified split, types with no care values at all, orphan cultivars, types with no plants, low-completeness types, and plants still unidentified), activity (new plants, care events logged, and contributions submitted/decided, per trailing week over the last several weeks), and operations (push-enabled users, pending email verifications, active API keys, and the applied migration count — counts only, never a secret, token, key or hash). No arguments; always reads the whole instance. Some values are legitimately absent rather than zero: a queue's age comes back as 'unknown' when its item type has no creation timestamp to measure from (pending user registrations have no such column), and the applied-migration count can be null when that guarded read failed — neither is a fabricated number. Read-only; nothing here writes. Requires an admin-scoped API key.", async () => apiGet("/api/v1/admin/dashboard"));
 }
 /**
  * Calls `/api/v1/me` once at startup to decide whether this key carries the

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@sebamomann/plants-mcp",
-  "version": "1.9.0",
-  "description": "MCP server for the Sprig plant app: 50 tools to read a plant collection, log care, edit a plant, and add, propagate or merge plants. Read-only by default; writes need a write-scoped API key. Two tools can delete a watering/fertilization event; nothing else is destructive. 17 more tools read, edit, merge and review the shared global plant type catalog for an admin-scoped key.",
+  "version": "2.5.0",
+  "description": "MCP server for the Sprig plant app: 76 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, 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 for an admin-scoped key.",
   "type": "module",
   "license": "MIT",
   "author": "sebamomann <github@sebamomann.de>",