@sebamomann/plants-mcp 2.0.0 → 2.5.1

package/CHANGELOG.md

@@ -3,6 +3,105 @@
 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.1 — 2026-09-20
+
+**Richer admin dashboard status.** Tool count unchanged (76 overall). A **patch** bump — the
+`admin_get_dashboard_status` response gains four optional groups, nothing renamed or removed:
+
+- `growth`, `community`, `trade`, `content` — accounts by status and care-active users, community
+  activity per week and open reports with age, aggregate deal/offer counts (never money or parties),
+  and photo/plant/analysis/notification totals. Each is independently `{ available: false }` when
+  its reads failed. See `docs/mcp-server.md`'s "Admin dashboard status".
+
+## 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

package/README.md

@@ -10,7 +10,7 @@ just ask:
 
 ## Quick start
 
-**1. Get an API key.** In Sprig: **Account → API keys → Generate**. It is shown once — copy it
+**1. Get an API key.** In Sprig: **Account → Settings → API keys → Generate**. It is shown once — copy it
 then. Pick read-only unless you actually want the assistant logging care; you can change a key's
 access level later without re-issuing it.
 
@@ -46,7 +46,7 @@ Requires **Node.js 20 or newer**. Nothing to install by hand: `npx` fetches the
 time your client starts the server.
 
 > 💡 The app has this guide built in, with your key and server address already filled in:
-> **Account → API keys → How to connect an assistant**.
+> **Account → Settings → API keys → How to connect an assistant**.
 
 ## What is Sprig?
 
@@ -60,18 +60,21 @@ needs a running Sprig instance and an API key from it. Start at the
 
 ## What an assistant can do
 
-**56 tools** over your collection: 22 that read it, 17 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.
+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, and the lookup catalogs. Writes cover recording waterings and fertilizings,
-health notes, dismissing care recommendations, editing a plant's identity/care schedule/settings,
-adding a plant (identified or not), propagating one, merging plants together and reversing that
-merge, deleting a watering or fertilization event, and managing the wishlist (add, note, remove).
+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`.
@@ -106,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 22 read tools.
-- **`write`** — opt-in when you create the key. Gates the 17 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.
@@ -132,9 +135,10 @@ Not oversights — deliberate limits:
   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` is a
-  third delete, but not in the same sense — a wish is a personal to-do item with no history to
-  lose, trivially re-added with `add_to_wishlist` if removed by mistake.
+  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
@@ -169,7 +173,7 @@ 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 |
 |---|---|---|
@@ -178,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
 
@@ -229,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
@@ -236,6 +242,11 @@ 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 |
@@ -247,6 +258,31 @@ catalog type, with its display/botanical name and `typeStatus`) or a free-text `
 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.
@@ -259,6 +295,10 @@ For resolving the ids the filters take.
 | `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
@@ -277,11 +317,14 @@ to do with the stub itself. A `REJECTED` id behaves the same way when its outcom
 (`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 17 ordinary write tools require a `write`-scoped key**; a read-only key gets HTTP 403. Every
+**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
@@ -290,6 +333,10 @@ description starts with `WRITE:` so a model cannot mistake one for a read.
 |---|---|---|
 | `record_watering` | `POST /api/v1/care/watering` | `plantIds` **(required,** 1–200**)**, `wateredAt` (`YYYY-MM-DD`, defaults to now, no future dates) |
 | `record_fertilization` | `POST /api/v1/care/fertilization` | `plantIds` **(required,** 1–200**)**, `fertilizerId`, `fertilizerPercent` (0–1000), `fertilizedAt` |
+| `record_repotting` | `POST /api/v1/plants/:id/repotting` | `plantId`, `potId` **(both required)**, plus `potSizeId`, `soilId`, `pottedAt`, `hasDrainage`, `hasClimbingAid`, `notes` |
+| `record_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
@@ -297,7 +344,23 @@ 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
 
@@ -349,6 +412,8 @@ don't exist yet, `propagate_plant` creates them *and* sets the link in one call.
 | `propagate_plant` | `POST /api/v1/plants/:id/propagations` | `plantId` **(required)**, `count` (1–10, default 1) |
 | `merge_plants` | `POST /api/v1/plants/merge` | `sourcePlantIds` **(required,** 1–200**)**, plus **exactly one of** `survivorPlantId` or `createNewFrom` |
 | `unmerge_plant` | `POST /api/v1/plants/:id/unmerge` | `plantId` **(required)** |
+| `set_plant_status` | `PATCH /api/v1/plants/:id/status` | `plantId`, `status` (`LIVING`\|`DEAD`\|`LOST`) **(both required)**, plus `deadDeclaredAt`/`deathCause` (only apply when `status` is `DEAD`) |
+| `set_plant_reference` | `PATCH /api/v1/plants/:id/reference` | `plantId`, `reference` (boolean) **(both required)** |
 
 `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
@@ -370,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 |
@@ -407,6 +487,52 @@ it is a configuration contradiction, fixed by editing the plant rather than hidd
 `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 |
@@ -438,13 +564,13 @@ 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 |
 |---|---|---|
@@ -454,6 +580,7 @@ includes `admin`.
 | `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, operational facts (counts only, never a secret), plus optional growth/community/trade/content aggregates (no money, no user details) |
 
 `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
@@ -469,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 (including the growth, community, trade and content blocks, each optional and individually `{ available: false }` if its read failed; trade is aggregate counts only, never a price or a party), 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`**
@@ -634,6 +768,6 @@ spec for the tool surface is `docs/mcp-server.md` at the repo root.
   variable, so it never lands in the tool arguments a model can see or echo. Treat it like a
   password.
 - Prefer a **read-only key** unless you specifically want an assistant logging care.
-- Revoke a key any time from **Account → API keys**; requests with it start returning 401
+- Revoke a key any time from **Account → Settings → API keys**; requests with it start returning 401
   immediately.
 - All data is scoped to the key's owner. Another user's data returns 404.

package/dist/apiClient.js

@@ -0,0 +1,103 @@
+/**
+ * The shared HTTP proxy every tool in `index.ts` is built on: `apiGet` for reads,
+ * `apiSend` for writes. Pulled into its own module so it can be unit-tested in
+ * isolation — `index.ts` has top-level side effects (env var validation that calls
+ * `process.exit`, `McpServer` construction, ~76 tool registrations, stdio connect)
+ * that make it unsafe to import directly in a test.
+ *
+ * Both functions take the API base URL and key as a config object rather than
+ * reading them from `process.env` themselves, so a test can point them at a mocked
+ * `fetch` with fixture values instead of needing real environment variables.
+ */
+export function createApiClient({ apiUrl, apiKey }) {
+    async function apiGet(path, query = {}) {
+        const url = new URL(`${apiUrl}${path}`);
+        for (const [key, value] of Object.entries(query)) {
+            if (value !== undefined && value !== "")
+                url.searchParams.set(key, String(value));
+        }
+        let res;
+        try {
+            res = await fetch(url, {
+                headers: {
+                    Authorization: `Bearer ${apiKey}`,
+                    Accept: "application/json",
+                },
+            });
+        }
+        catch (err) {
+            return {
+                content: [{ type: "text", text: `Network error calling ${url.pathname}: ${String(err)}` }],
+                isError: true,
+            };
+        }
+        const body = await res.text();
+        if (!res.ok) {
+            return {
+                content: [
+                    {
+                        type: "text",
+                        text: `Request to ${url.pathname} failed (HTTP ${res.status}): ${body || res.statusText}`,
+                    },
+                ],
+                isError: true,
+            };
+        }
+        // Pretty-print JSON when possible, otherwise return raw text.
+        let text = body;
+        try {
+            text = JSON.stringify(JSON.parse(body), null, 2);
+        }
+        catch {
+            // leave as-is
+        }
+        return { content: [{ type: "text", text }] };
+    }
+    /**
+     * Sends a JSON body to a mutating endpoint. Requires an API key with the
+     * `write` scope — a read-only key gets a 403 surfaced back to the model verbatim
+     * so it can tell the user their key can't write. `DELETE` sends no body.
+     */
+    async function apiSend(method, path, body) {
+        const url = new URL(`${apiUrl}${path}`);
+        let res;
+        try {
+            res = await fetch(url, {
+                method,
+                headers: {
+                    Authorization: `Bearer ${apiKey}`,
+                    Accept: "application/json",
+                    ...(body ? { "Content-Type": "application/json" } : {}),
+                },
+                ...(body ? { body: JSON.stringify(body) } : {}),
+            });
+        }
+        catch (err) {
+            return {
+                content: [{ type: "text", text: `Network error calling ${url.pathname}: ${String(err)}` }],
+                isError: true,
+            };
+        }
+        const text = await res.text();
+        if (!res.ok) {
+            return {
+                content: [
+                    {
+                        type: "text",
+                        text: `Request to ${url.pathname} failed (HTTP ${res.status}): ${text || res.statusText}`,
+                    },
+                ],
+                isError: true,
+            };
+        }
+        let pretty = text;
+        try {
+            pretty = JSON.stringify(JSON.parse(text), null, 2);
+        }
+        catch {
+            // leave as-is
+        }
+        return { content: [{ type: "text", text: pretty }] };
+    }
+    return { apiGet, apiSend };
+}

package/dist/index.js

@@ -3,6 +3,7 @@ import { readFileSync } from "node:fs";
 import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
 import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
 import { z } from "zod";
+import { createApiClient } from "./apiClient.js";
 /**
  * MCP server for the Sprig plant app: reads the collection, and — with a
  * write-scoped key — logs care, edits a plant, and deletes a watering or
@@ -31,95 +32,7 @@ if (!API_KEY) {
     console.error("[plants-mcp] Missing PLANT_API_KEY environment variable.");
     process.exit(1);
 }
-async function apiGet(path, query = {}) {
-    const url = new URL(`${API_URL}${path}`);
-    for (const [key, value] of Object.entries(query)) {
-        if (value !== undefined && value !== "")
-            url.searchParams.set(key, String(value));
-    }
-    let res;
-    try {
-        res = await fetch(url, {
-            headers: {
-                Authorization: `Bearer ${API_KEY}`,
-                Accept: "application/json",
-            },
-        });
-    }
-    catch (err) {
-        return {
-            content: [{ type: "text", text: `Network error calling ${url.pathname}: ${String(err)}` }],
-            isError: true,
-        };
-    }
-    const body = await res.text();
-    if (!res.ok) {
-        return {
-            content: [
-                {
-                    type: "text",
-                    text: `Request to ${url.pathname} failed (HTTP ${res.status}): ${body || res.statusText}`,
-                },
-            ],
-            isError: true,
-        };
-    }
-    // Pretty-print JSON when possible, otherwise return raw text.
-    let text = body;
-    try {
-        text = JSON.stringify(JSON.parse(body), null, 2);
-    }
-    catch {
-        // leave as-is
-    }
-    return { content: [{ type: "text", text }] };
-}
-/**
- * Sends a JSON body to a mutating endpoint. Requires an API key with the
- * `write` scope — a read-only key gets a 403 surfaced back to the model verbatim
- * so it can tell the user their key can't write. `DELETE` sends no body.
- */
-async function apiSend(method, path, body) {
-    const url = new URL(`${API_URL}${path}`);
-    let res;
-    try {
-        res = await fetch(url, {
-            method,
-            headers: {
-                Authorization: `Bearer ${API_KEY}`,
-                Accept: "application/json",
-                ...(body ? { "Content-Type": "application/json" } : {}),
-            },
-            ...(body ? { body: JSON.stringify(body) } : {}),
-        });
-    }
-    catch (err) {
-        return {
-            content: [{ type: "text", text: `Network error calling ${url.pathname}: ${String(err)}` }],
-            isError: true,
-        };
-    }
-    const text = await res.text();
-    if (!res.ok) {
-        return {
-            content: [
-                {
-                    type: "text",
-                    text: `Request to ${url.pathname} failed (HTTP ${res.status}): ${text || res.statusText}`,
-                },
-            ],
-            isError: true,
-        };
-    }
-    let pretty = text;
-    try {
-        pretty = JSON.stringify(JSON.parse(text), null, 2);
-    }
-    catch {
-        // leave as-is
-    }
-    return { content: [{ type: "text", text: pretty }] };
-}
+const { apiGet, apiSend } = createApiClient({ apiUrl: API_URL, apiKey: API_KEY });
 const server = new McpServer({ name: "plants-mcp", version: VERSION });
 // --- Identity ---------------------------------------------------------------
 server.tool("whoami", "Return the authenticated user for the configured API key.", async () => apiGet("/api/v1/me"));
@@ -152,6 +65,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 +120,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,6 +149,38 @@ server.tool("record_fertilization", "WRITE: log a fertilization for one or more
         .describe("Strength as a percentage of the base dose; defaults to each plant's own."),
     fertilizedAt: optionalPlantDate(""),
 }, async (args) => apiSend("POST", "/api/v1/care/fertilization", { ...args }));
+server.tool("record_repotting", "WRITE: log a repotting — new pot, and optionally a new soil mix and/or pot size. Re-derives the plant's current soil from its latest potting event, and syncs watering/fertilizing mode when the new pot's self-watering flag changes it (the same way the app's own repotting form does). pottedAt defaults to today, or to the plant's acquiredAt date if this is its very first-ever potting event. Requires a write-scoped API key.", {
+    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."),
@@ -326,6 +273,19 @@ 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
@@ -346,6 +306,34 @@ server.tool("add_wishlist_note", "WRITE: add a dated note to a wish — price, w
 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"));
 /**
@@ -366,8 +354,54 @@ const publicPlantTypeListArgs = {
 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
@@ -492,6 +526,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). Four more optional groups follow, each independently `{ available: false }` when its reads failed: growth (accounts by status, care-active users over 7/30 days, active users with no plant, users with push or an API key — sign-ups per week are not tracked), community (posts/comments/reactions per week, open reports with age, muted users, follows, active share links), trade (aggregate deal and offer counts by status, sold vs gifted vs traded, wishlist size — never prices, money or parties), and content (photos and 30-day growth, living vs archived plants, plant analyses, AI plausibility checks, notifications sent vs read over 30 days). 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": "2.0.0",
-  "description": "MCP server for the Sprig plant app: 56 tools to read a plant collection, browse the shared global plant type catalog, log care, edit a plant, add, propagate or merge plants, and manage a wishlist. Read-only by default; writes need a write-scoped API key. Two tools can delete a watering/fertilization event; nothing else deletes collection history. 17 more tools read, edit, merge and review the shared global plant type catalog for an admin-scoped key.",
+  "version": "2.5.1",
+  "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 (queues, catalog health, activity, growth, community, trade and content aggregates) for an admin-scoped key.",
   "type": "module",
   "license": "MIT",
   "author": "sebamomann <github@sebamomann.de>",
@@ -44,6 +44,8 @@
     "dev": "tsx src/index.ts",
     "typecheck": "tsc --noEmit",
     "check:docs": "node scripts/check-tool-docs.mjs",
+    "test": "vitest run",
+    "test:watch": "vitest",
     "prepublishOnly": "npm run build"
   },
   "dependencies": {
@@ -52,6 +54,7 @@
   },
   "devDependencies": {
     "@types/node": "^26.1.1",
-    "typescript": "^6.0.3"
+    "typescript": "^6.0.3",
+    "vitest": "^4.1.10"
   }
 }