Errand Runs MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ERRANDS_PATH | No | Path to the local JSON file where errand data is stored. By default it lives at data/errands.json inside the project. | data/errands.json |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| log_itemA | Log one errand item and tag it with the store(s) that can sell it (for example ["Canal Market", "Maple Drugstore"]). Quantity defaults to 1. Leaving stores empty still logs the item, but it cannot be planned into a run until it has a store tag. |
| tallyA | Show the open list grouped by store tag, with a count per store (busiest first). This is the quick 'how long is each store's list' view before planning a run. |
| plan_runA | Plan one low-energy errand run: a single trip covering at most
|
| mark_boughtA | Close an item as bought: reference it by id (I-3) or name
('oat milk'). Price is what you paid, if you want it on the receipt.
For items tagged with several stores, say which store it came from
using |
| receiptA | After-the-fact closure query: the receipt for one trip day (YYYY-MM-DD, default today). Lists what was bought, per-store subtotals, the total paid, and where the open list stands. |
| list_itemsA | List logged items: 'open' (default) for things still to buy, 'bought' for closed ones, 'all' for both. Handy for double-checking the log before planning or closing a run. |
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 fairly distinct role: logging (log_item), aggregate views (tally), planning (plan_run), closure (mark_bought), historical query (receipt), and filtered listing (list_items). The only mild overlap is between tally and list_items, both read views, but their descriptions clearly differentiate grouped-by-store counts from item-level status filtering.
Four tools follow a clean verb_noun or verb_object pattern (log_item, list_items, mark_bought, plan_run). The remaining two (tally, receipt) are bare/single-word names, which is a minor deviation but still readable and semantically apt.
Six tools is a tight, well-scoped surface for a personal errand-planning server. Every tool maps to a distinct stage of the workflow (log, review, plan, close, report, audit) with no filler.
The lifecycle of logging, planning, closing, and reporting is covered, but there is no way to update an item (fix quantity, retag a store) or delete/undo a mistakenly logged entry or purchase. These are notable gaps that would force workarounds for common corrections.