bookmarks-lifecycle
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CHROMIUM_BOOKMARKS_PATH | No | Optional comma-separated list of custom Chromium profile paths with /Bookmarks appended, to include non-standard browser profiles. | |
| BOOKMARKS_LIFECYCLE_STATE_DIR | No | Where state.json (and its lock/backup files) live. | ~/.bookmarks-lifecycle |
| BOOKMARKS_LIFECYCLE_AUTO_DECIDE | No | Whether decide/restore/undo calls claiming actorClaim: 'ai' are allowed through. Not a security guarantee. | false |
| BOOKMARKS_LIFECYCLE_DRIP_PER_DAY | No | Max inbox items promoted to pending per day (never accumulates across a gap). | 15 |
| BOOKMARKS_LIFECYCLE_PENDING_HOURS | No | Hours in the pending layer before an undecided item lapses. | 24 |
| BOOKMARKS_LIFECYCLE_WATCHING_DAYS | No | Days in the watching layer before an undecided item lapses. | 30 |
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": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| intakeA | Scan browser bookmarks (via bookmarks-mcp) and merge them into the lifecycle: new URLs land in |
| todayA | The 24-hour layer, oldest first — the actual to-do list. Each item includes |
| decideA | MUTATING TOOL. Never call until the user has explicitly confirmed the exact item ids and action in the current turn, unless the MCP host has a trusted autonomous-approval mode enabled — silence, "looks good", or an earlier preference is not confirmation. Moves items to |
| list_layerA | See what's in one layer — including |
| restoreA | MUTATING TOOL. Move one or more |
| undoA | MUTATING TOOL. Revert an item to whatever it was immediately before one of ITS OWN history events — this works for |
| statsA | Counts per layer, how many decisions landed today (local calendar day on the machine running this server — see README), and how much is still sitting in |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| clean_up_my_bookmarks | First-time walkthrough: explain the decision-clock mechanism, scan your bookmarks, and run one small triage round together. |
| daily_triage | The daily entry point: see what's due today, get a suggestion per item, and only change anything once you've confirmed it. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Most tools have clearly distinct purposes: intake scans, decide mutates, stats aggregates, undo/restore handle reversal. However, list_layer and today overlap somewhat in that today is essentially a specialized view of the pending layer with extra metadata, which could cause an agent to pick either when trying to see pending items.
Tool names are a mix of single verbs (intake, decide, restore, undo), single nouns (stats, today), and one snake_case verb_noun (list_layer). There is no consistent verb_noun or action-oriented pattern, making the set feel stylistically inconsistent.
Seven tools is well-scoped for a bookmark lifecycle server. Each tool addresses a distinct stage or operation (ingestion, viewing, deciding, stats, reversal), with no trivial or redundant tools.
The lifecycle is well covered: intake brings items in, today/list_layer expose them, decide moves them, restore/undo handle reversals, and stats provides feedback. Minor gaps include no direct way to edit item metadata outside of rescanning, but this does not block core workflows.