@sebamomann/plants-mcp 2.8.1 → 2.8.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -3,6 +3,19 @@
3
3
  Notable changes to `@sebamomann/plants-mcp`. Versioning is semver against the **tool surface** —
4
4
  see the table in `AGENTS.md` for what counts as major, minor, and patch.
5
5
 
6
+ ## 2.8.2 — 2026-09-29
7
+
8
+ **Correction to 2.8.1.** Tool count unchanged (78). A **patch** bump — nothing renamed or removed:
9
+
10
+ - 2.8.1 said a plant with no watering schedule (reservoir/hydro) gets no fertilizing entry from
11
+ `list_due_care`, `list_overdue_care` or `get_care_calendar`. That was too broad and is reverted:
12
+ such a plant has no watering for a feeding to attach itself to, so its `wateringAlignedOn` is
13
+ always `null` and the feeding stays on its own due date — but it is still listed, like any other
14
+ task. Those plants are fertilized from the app's fertilizing view, where the combined button
15
+ records a refill (hydro: a top-up) instead of a watering event; dropping them removed a real
16
+ capability. Anyone who read 2.8.1's note and stopped asking about reservoir plants' feedings
17
+ should start again.
18
+
6
19
  ## 2.8.1 — 2026-09-29
7
20
 
8
21
  **Fertilizing schedule reads now match the app's calendar exactly.** Tool count unchanged (78
package/README.md CHANGED
@@ -214,8 +214,8 @@ Four things to know when reading schedule results:
214
214
  `get_care_calendar` buckets the entry there instead of under its own date, and
215
215
  `list_due_care`/`list_overdue_care` judge their window/overdue membership by the same day.
216
216
  `nextDue` keeps its own meaning throughout — the feeding's own due date. A plant with no watering
217
- schedule (reservoir/hydro) never gets a fertilizing entry from these tools at all, matching the
218
- calendar's own reservoir view.
217
+ schedule (reservoir/hydro) has nothing to attach a feeding to, so its `wateringAlignedOn` is always
218
+ `null` and the feeding stays on its own date — it is still a real task.
219
219
  - **Recommendations return i18n message keys plus values**, not rendered prose. Dismissed ones are
220
220
  excluded.
221
221
 
package/dist/index.js CHANGED
@@ -99,7 +99,7 @@ server.tool("list_due_care", "What needs water or fertilizer now: overdue work p
99
99
  .describe("Include already-overdue work (default true)."),
100
100
  }, async (args) => apiGet("/api/v1/care/due", { ...args, includeOverdue: args.includeOverdue?.toString() }));
101
101
  server.tool("list_overdue_care", "Only work whose due date has already passed, most overdue first, with how many days each is late. Use for 'what have I fallen behind on?'. A feeding waiting on a future watering (`wateringAlignedOn` set — see `get_care_calendar`) is not listed here even when its own `nextDue` has passed: it's due on the watering's day, not neglected.", careArgs, async (args) => apiGet("/api/v1/care/overdue", args));
102
- server.tool("get_care_calendar", "Day-by-day care schedule over a date range, plus an overdue group. Each plant appears on its next due day only — this projects the current schedule rather than simulating future waterings. Fertilizing follows the app calendar's water-align rule: a feeding due before a plant's next watering is bucketed there unconditionally, and one due shortly after may ride along with it (within a third of the watering interval, capped at a quarter of the feeding's own cycle) — either way the fertilizing entry's `wateringAlignedOn` (YYYY-MM-DD) names that day and the bucket it's placed in follows it, while `nextDue` keeps the feeding's own, unchanged due date. A plant with no watering schedule (reservoir/hydro) never gets a fertilizing entry here at all — its fertilizing is entirely the reservoir view's job.", {
102
+ server.tool("get_care_calendar", "Day-by-day care schedule over a date range, plus an overdue group. Each plant appears on its next due day only — this projects the current schedule rather than simulating future waterings. Fertilizing follows the app calendar's water-align rule: a feeding due before a plant's next watering is bucketed there unconditionally, and one due shortly after may ride along with it (within a third of the watering interval, capped at a quarter of the feeding's own cycle) — either way the fertilizing entry's `wateringAlignedOn` (YYYY-MM-DD) names that day and the bucket it's placed in follows it, while `nextDue` keeps the feeding's own, unchanged due date. A plant with no watering schedule (reservoir/hydro) has no watering to attach a feeding to, so its `wateringAlignedOn` is always null and the feeding stays on its own due date.", {
103
103
  ...careArgs,
104
104
  days: z.number().int().min(1).max(60).optional().describe("Number of days to project (default 14, max 60)."),
105
105
  }, async (args) => apiGet("/api/v1/care/calendar", args));
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@sebamomann/plants-mcp",
3
- "version": "2.8.1",
3
+ "version": "2.8.2",
4
4
  "description": "MCP server for the Sprig plant app: 78 tools to read a plant collection, browse the shared global plant type catalog, log care (watering, fertilizing, repotting, refills, hydro events), edit a plant's identity/care/lifecycle status, add, propagate or merge plants, snooze a due date, check for nudges worth mentioning, manage a wishlist and notifications, watch a plant type for changes, check vacation status, read past problem diagnoses, create a location/soil/fertilizer/pot, and contribute a new species to the catalog. Read-only by default; writes need a write-scoped API key. Two tools can delete a watering/fertilization event; nothing else deletes collection history. 18 more tools read, edit, merge and review the shared global plant type catalog and the instance's operational status (queues, catalog health, activity, growth, community, trade and content aggregates) for an admin-scoped key.",
5
5
  "type": "module",
6
6
  "license": "MIT",