HomeStock
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HOMESTOCK_DB | No | Path to the SQLite database file. Defaults to ./homestock.db if not set. | ./homestock.db |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| add_itemsA | Record a purchase (one receipt). Idempotent per (source_ref, line_no). Each item: {name, quantity, unit, price?, category?, line_no}. source: 'email' (purchased_at required — the receipt has a date) or 'manual' (purchased_at defaults to today). source_ref: retailer ORDER ID where extractable, else email Message-ID; manual fallback 'manual:::' (+':2' suffix on collision — a nonzero 'ignored' count on a fresh receipt signals one). Call get_stock() first and reuse existing item names exactly. Returns {inserted, ignored, rejected: [{line_no, reason}]}. |
| get_stockA | Current stock estimate. No argument: list all known items as {name, category} — call this before add_items to reuse exact names. With an item name: naive-baseline estimate with raw provenance (estimated_state is 'unknown' below 2 distinct purchase dates). |
| what_should_i_orderA | Items past their typical repurchase interval: >= 3 distinct purchase dates, days_since >= median interval, excluding items past 3x median (presumed discontinued). Sorted by overshoot ratio, highest first. |
| void_eventA | Correction path: void matching event lines (all lines of the receipt if line_no omitted). Voided rows are excluded from every estimate; re-inserting a corrected line for the same (source_ref, line_no) then works. Returns {voided: n}; zero matches is a no-op, not an error. |
| record_ingest_runA | Ingestion agent plumbing: record a run (heartbeat + audit) after every ingestion pass, even one that wrote nothing. skipped: [{source_ref, reason}] for receipts/lines the agent could not parse (never guess — skip and log). Returns the backfill cursor: earliest_window_start already covered. |
| get_eventsA | Read-only raw event access (explainability: every estimate is recomputable from these rows). Includes voided rows, flagged. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool has a distinct purpose: querying stock estimates, voiding events, logging ingestion runs, accessing raw events, recording purchases, and generating reorder suggestions. There is no overlap or ambiguity between them.
Most tools follow a clear verb_noun convention (get_stock, void_event, record_ingest_run, get_events, add_items), but what_should_i_order breaks the pattern as a sentence-style question, creating a minor inconsistency.
With 6 tools, the set is well-scoped for a home stock management server—enough to cover core operations without being bloated or too thin.
The tool set provides full lifecycle coverage for event-based stock estimation: adding purchases, voiding corrections, reading raw events, querying estimates, and receiving reorder recommendations. No obvious gaps or dead ends exist for the stated domain.