Datacron
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DATACRON_DURABILITY | No | Durability mode (e.g., 'best-effort'). | |
| DATACRON_READ_PATHS | Yes | Read allowlist; if empty, read tools are disabled. Setup typically sets this to the vault root. | |
| DATACRON_VAULT_ROOT | Yes | Vault served by the server (default: current directory or --vault) | |
| DATACRON_WRITE_PATHS | No | Write allowlist; empty disables write tools. | |
| DATACRON_RIPGREP_PATH | No | Path to the ripgrep binary. | rg |
| DATACRON_CHUNK_MAX_TOKENS | No | Target maximum chunk size in tokens. | 1024 |
| DATACRON_MAX_RESULT_COUNT | No | Maximum number of results returned. | 20 |
| DATACRON_MAX_RESULT_TOKENS | No | Token budget for search results. | 8000 |
| DATACRON_GET_NOTE_MAX_TOKENS | No | Token budget for get_note(format='full'). | 25000 |
| DATACRON_REPAIR_MIN_INTERVAL_SECONDS | No | Minimum interval between repair-on-read sweeps; 0 = on every read. | 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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| session_contextA | Start memory-dependent work here. Return the versioned common discipline, effective write capability and bounded live notes. Optional subject finds ranked candidates without repairing the index. Coverage is explicit; candidates never establish a person's identity. Read next pages before relying on incomplete context. |
| prepare_follow_upA | Validate sourced actions, interactions, objectives and state revisions against live note IDs/hashes and exact source excerpts. Existing target history headings are required. Person targets require contextual identity confirmation; clarify homonyms first. Returns bounded append_journal plans, never writes. Validation is structural, not a truth verdict. Use stable record/revision IDs, then apply with existing writers and verify receipts. Schema constraints, repeated because some clients strip them: required: record_id, revision, kind, target_path, target_id, expected_hash, heading, source_path, source_hash, source_excerpt, summary; extra fields refused; at most 20 records per call, checked at runtime; record_id: pattern ^[A-Za-z0-9][A-Za-z0-9_.-]{0,127}$; revision: pattern ^[A-Za-z0-9][A-Za-z0-9_.-]{0,127}$; previous_revision: pattern ^[A-Za-z0-9][A-Za-z0-9_.-]{0,127}$, or null, default null; kind: one of action, interaction, decision, objective, project_state; target_path: 1 to 4000 characters; target_id: pattern ^[0-9A-HJKMNP-TV-Z]{26}$; expected_hash: pattern ^[0-9a-f]{64}$; heading: 1 to 256 characters; source_path: 1 to 4000 characters; source_hash: pattern ^[0-9a-f]{64}$; source_excerpt: 1 to 4000 characters; summary: 1 to 4000 characters; event_date: ISO date, or null, default null; owner: at most 256 characters, or null, default null; due_date: ISO date, or null, default null; status: one of unknown, proposed, open, in_progress, waiting, completed, cancelled, default "unknown"; identity_confirmed: boolean, default false; identity_basis: at most 1000 characters, or null, default null |
| get_follow_upA | Read latest structured follow-up revisions in explicit canonical notes. Completed/cancelled records are hidden by default; history remains intact. Legacy prose is not parsed and source freshness is not revalidated. Use get_note for legacy notes and original evidence; absence is not proof that no commitments exist. Continue with next_offset and expected_snapshot=snapshot_hash, keeping note_paths and include_closed unchanged. Restart from offset 0 if sources change. |
| list_notesA | Use this to discover vault structure before deeper reads. Return an offset/limit paginated list of notes in the vault, optionally scoped to a subfolder and/or filtered by tags or top-level frontmatter (for example, frontmatter={'confidence': 'needs_verification'}). Each entry includes the stable ULID, title, tags, aliases, and timestamps. |
| get_noteA | Fetch the full context behind a search hit before answering from a snippet alone. Fetch a single note by its ULID, indexed chunk_id, or vault-relative path. chunk_id inputs return format='chunk' with the sandbox-wrapped chunk body; a parent-hash mismatch returns an explicit stale-chunk error. Chunk reads ignore offset/limit. For note inputs, format='full' returns the sandbox-wrapped body and offset/limit page large notes by character range; format='map' returns the heading outline only (cheap to scan before requesting full content). heading_path selects exact rendered heading ancestry including its subtree; repeated paths require a 1-based heading_occurrence. Section reads require full format and a note input, include source line spans and the original note hash, and paginate relative to the redacted section. |
| search_textA | First stop for any question about the user's notes, projects, decisions, or past work - search before saying you do not know. Full-text BM25 search over the FTS5 index; note titles and heading trails carry extra weight. Returns ranked sandbox-wrapped snippets with term highlighting. Narrow the scope with |
| search_regexA | Regex search via ripgrep. Returns ranked sandbox-wrapped match lines with term highlighting, resolved to indexed chunks. Restrict file scope with |
| get_backlinksA | Use this to find related context the user did not mention. Return chunks whose wikilinks point at the given target. Target may be a note ULID or a wikilink alias (resolved via title -> filename -> aliases). Empty list if unresolved or no incoming links. |
| contradiction_scanA | Use this when indexed sections may conflict or refine one another. Scan mode returns deterministic section-level candidates and read-only proposal tokens; summary detail omits redundant alternative previews while full detail retains them for debugging. confirm mode validates one token and returns an exact existing write-tool call. This tool never writes, including after elicitation or confirmation. |
| get_healthA | Return truthful read-only health for index freshness, vault integrity, point-in-time checksum, durability capability, and invariant evidence. Use detail='full' to include bounded integrity findings. In full mode, limit <= 0 selects the server ceiling and positive limits are capped by settings.max_result_count. Fingerprints are opaque baseline identifiers derived from raw keys, not hashes of sanitized published keys. Only top-level violation rel_path and mixed_eol_notes entries preserve addressable paths; details such as candidate_paths are sanitized display metadata. Findings do not include line numbers. |
| create_note_aiA | Call this proactively when a durable fact, confirmed decision, or user preference emerges in conversation - do not wait to be asked. Skip speculation and one-off chatter. Write a new typed _memory Markdown note. Use rejected entries in 'option -- reason' format to record discarded options so a future agent does not propose them again. This is a write operation: it is confined to DATACRON_WRITE_PATHS, never overwrites existing files, writes a durable operation record, and relies on the MCP client's tool approval for human-in-the-loop review. |
| append_journalA | Use this when new information extends a topic that already has a note, instead of creating a duplicate. Append a Markdown entry under a heading in an existing memory note. This is a write operation: it is confined to DATACRON_WRITE_PATHS, stores content-addressed history, writes atomically, and relies on the MCP client's tool approval for human-in-the-loop review. |
| set_frontmatterA | Use this when a fact's lifecycle changes: verified today, superseded by a newer note, or confidence raised or lowered. Prefer invalidating an outdated fact (invalid_at + invalidated_by) over deleting or rewriting it: history stays queryable. Use rejected entries in 'option -- reason' format to record discarded options so a future agent does not propose them again. Update frontmatter fields on an existing memory note. This write operation only changes origin, confidence, last_verified, supersedes, rejected, valid_from, invalid_at, invalidated_by, last_id, and the automatic updated timestamp. last_id requires expected_hash, accepts BL- plus at least four ASCII digits, and cannot decrease an existing valid counter. The Markdown body is preserved. |
| patch_note_preambleA | Use this to replace or remove content strictly before the first Markdown heading recognized by the current write selector. Pass the note's exact expected_hash for CAS. Empty or whitespace-only new_content removes the preamble. The first heading and all following content preserve exact bytes when the file uses uniform line endings; mixed-EOL files follow the existing global dominant-EOL normalization. Notes without a recognized Markdown heading are refused fail-closed. The shared AST selector supports ATX and Setext headings, normalizes closing hashes, and ignores headings inside fenced code. |
| patch_note_sectionA | Use this to rewrite an outdated section in place when the topic already has a note. Replace the content under one existing Markdown heading. Pass the note's current content_hash as expected_hash for CAS. The operation preserves the heading line and non-target sections, stores exact prior history, and writes atomically. It refuses a level-1 heading that contains subsections; patch a lower-level heading instead. For duplicate titles, pass 1-based heading_occurrence with heading_level and the exact expected_hash; the ordinal follows document order for those hashed bytes. Do not use chunk_id. |
| rename_note_sectionA | Use this only to rename an outdated H2-H6 Markdown section title recognized by the current write selector, without changing its level, content, or subordinate headings. Pass the note's current content_hash as expected_hash for CAS. It refuses H1 because frontmatter title synchronization is outside this tool and refuses collisions recognized by the same AST selector. ATX and Setext headings are supported; fenced-code headings are ignored. For duplicate titles, pass 1-based heading_occurrence with heading_level and the exact expected_hash; the ordinal follows document order for those hashed bytes. Do not use chunk_id. |
| delete_note_sectionA | Use this only to remove an explicitly obsolete H2-H6 Markdown section and all of its subordinate headings. Prefer lifecycle invalidation with set_frontmatter when the fact must remain queryable. Pass the note's current content_hash as expected_hash for CAS. The operation stores exact prior history, writes atomically, and refuses every level-1 heading. For duplicate titles, pass 1-based heading_occurrence with heading_level and the exact expected_hash; the ordinal follows document order for those hashed bytes. Do not use chunk_id. |
| move_note_sectionA | Use this to preview an exact single-note H2-H6 subtree move to an existing heading's final child position. Both headings must exist; no releveling. Requires expected_hash. Default confirm=false returns selection coordinates and before/projected hashes without writing; confirm=true commits with durable history and index reconciliation. Preserves all text and frontmatter bytes; mixed EOLs, unsafe boundaries and invalid child hierarchy are refused. AST selectors support ATX/Setext and ignore fences. Duplicate titles require the respective level and 1-based occurrence. Use a stable request_id when committing for durable replay receipts. |
| revert_noteA | Use this to undo a bad write by restoring exact prior bytes. Restore a note to exact content-addressed history bytes. Pass the current content_hash as expected_hash for CAS. The revert is itself durable, reversible, indexed, and operation-logged. |
| get_note_historyA | Filter by request_id to retrieve an ordinary-write receipt. List committed operation metadata for one note without reading history content or modifying the journal. |
| audit_queryA | Query committed operation metadata by time range, tool, or note. This read-only operation never changes the journal or vault. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| vault-map | Folder/file tree with titles and tags. Lightweight (~2k tokens). |
| vault-info | Stats about the vault: path, note count, index freshness. |
| policy-active | Current write-policy state and availability of the L0-L5 trust engine. |
TDQS
Scored across 21 tools
Most tools target clearly distinct operations (search vs regex, distinct section verbs move/rename/delete/patch), and the verbose descriptions clarify boundaries. However, get_note_history and audit_query both read committed operation metadata and overlap substantially (the former is essentially a single-note filter of the latter), and create_note_ai vs append_journal requires judgment about when to create new versus extend.
Names are uniformly snake_case and predominantly verb-first (get_, set_, move_, prepare_, list_, search_, create_, append_, patch_, rename_, delete_, revert_). A few are noun-first (contradiction_scan, session_context, audit_query), which is a minor deviation but still readable and consistent in casing.
21 tools is on the heavy side for what is fundamentally a notes/memory server. The section-level variants (move/rename/delete/patch_section/patch_preamble) plus overlapping metadata readers inflate the surface, though each does target a distinct operation.
The surface covers the full note lifecycle: discovery (list/search/get/backlinks), creation (create_note_ai/append_journal), frontmatter lifecycle, precise section editing, deletion, revert from content-addressed history, plus history, audit, health, and follow-up tracking. No obvious dead ends for the stated vault-memory purpose.