agentcheckpoint
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CHECKPOINT_DB_PATH | No | Ruta de la base de datos SQLite | ~/.hermes/checkpoints.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
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_stateA | Read the current value of a checkpoint by key. Returns the latest stored JSON value, its version, and update timestamp. Returns {"status": "not_found"} if key doesn't exist. |
| set_stateA | Atomically write a checkpoint with optional version guard. Pass expected_version from a prior get_state call. expected_version=0 → create-only (fails if key exists). expected_version=N → update only if stored version matches (conflict-safe). Omit expected_version or pass -1 → unconditional write. Use force_set_state for simpler unconditional writes. |
| force_set_stateA | Unconditionally write a checkpoint value. Always succeeds. Prefer for single-writer workflows. For concurrent writers, use set_state with expected_version. |
| list_stateA | List checkpoint keys matching a pattern (SQL LIKE syntax). Pass '%' or omit for all keys. Returns key, version, and updated_at for each match. |
| delete_stateA | Remove a checkpoint key and its value permanently. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Usage Patterns | How to use agentcheckpoint: single-writer, multi-agent OCC, key naming, anti-patterns |
| Multi-Agent Coordination | OCC pattern for multi-agent workflows with conflict detection |
| Key Naming Convention | Standard key structure and naming best practices |
TDQS
Scored across 5 tools
set_state and force_set_state both perform writes, with set_state also supporting unconditional writes via omitted expected_version. The descriptions clarify intended use cases (concurrency-safe vs. simple writes), but the overlap creates a minor selection risk. Other tools are clearly distinct.
All tools follow a clear [verb]_state pattern: get_state, set_state, force_set_state, list_state, delete_state. The compound verb force_set is still consistent and predictable.
Five tools is well-scoped for a checkpoint store, covering read, write, list, delete, and a conditional-write variant without clutter or redundancy.
The set covers the full lifecycle: create (set_state with version 0), read (get_state), update (set_state with version), delete (delete_state), and listing (list_state). The force_set_state adds a convenience write, leaving no obvious gaps.