Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
TRACKER_DB_PATHNoDurable SQLite file; use an absolute path in client configurationtracker.db
TRACKER_ACTOR_IDNoConfigured attribution and review-ticket scopelocal-agent
TRACKER_WORKSPACE_IDNoLocal data partitionlocal

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
batch_readA

Read 1–10 mixed searches, contexts, traversals or catalogs in one consistent snapshot. Searches accept text (full-text) and may include_context to return full records and one-hop links for the page. operation 'traverse' takes the traverse tool's arguments, with max_nodes capped at 100 here; operation 'aggregate' takes the aggregate tool's arguments. Total search limits plus traverse max_nodes (default 50) plus standalone context/catalog/aggregate items must be <=100. Each search retains its own next_cursor. Context event_limit defaults to 0 (omitted, not absent); set 1–100 for history. Relationship limits apply per direction. Ordered results carry item_index; any failure rejects the call. Max response 2 MB. Reads do not authorize writes: use resolution tickets for those.

batch_resolve_recordsA

Resolve 1–10 names/IDs together with the same safeguards as resolve_record. Returns ordered, independent resolution tickets and candidate context. Handle each ambiguous or misspelled name separately; batching is not identity confirmation.

prepare_batch_writeA

Preview 1–10 existing-record writes atomically; returns one action_id. Each item uses the argument shape documented by prepare_write, its review_ids, decision_reason and optional actual clarification. All reviews are validated against the same initial snapshot. Items then execute in order with version checks; repeated writes to one record must use successive expected_version values. Nothing is changed. Creation and collection changes use the existing single-write discovery workflow. Any failing operation rejects the entire batch with a zero-based item_index.

commit_batch_writeA

Commit the prepared batch all-or-nothing, including per-item audit evidence. Freshness/actor/workspace and versions are checked. Expiry is 15 minutes. Retry the same successful action_id safely, including after server restart. On failure no item commits; refresh stale reviews, never blindly substitute versions.

prepare_importA

Prepare creating up to 100 records in ONE existing collection, with optional links, in two calls instead of three per record. No per-title resolution is needed: the server checks every row title against every title and alias in the collection (archives included) and against the other rows, with the same similarity rules as resolve_record. rows: [{key, title, data}] where key is your own unique label for the row. links: [{source, relationship_type, target}]; each endpoint is {"row": key} or {"record_id": id}. Existing record endpoints need resolution tickets in review_ids (clarification applies to those). Returns per-row status clean / possible_duplicate / batch_duplicate with candidates, the keys in needs_decision, a preview and action_id. Nothing is written. Very large collections limit rows per call; the error says how many.

commit_importA

Commit a prepared import atomically. decisions must cover exactly the keys in needs_decision: {"action": "skip"}, {"action": "use_existing", "record_id": <one of that row's candidates>} (its links attach to the existing record), or {"action": "create_anyway", "clarification": }. Rows that only resemble each other need no clarification once the others are skipped or reused. Links to skipped rows are dropped and reported. Stale if any name in the collection changed since prepare: prepare again. A committed action_id can be retried safely.

discover_collectionsA

Review the existing catalog BEFORE collection creation. Returns full names, purposes, aliases, representative records and lexical suggestions, plus discovery_id. Read all catalog entries by meaning; synonyms can have no shared words. Incomplete review cannot authorize creation. Prefer reuse when purpose fits; do not ask routinely.

resolve_recordA

Resolve a name, misspelling, confirmed alias or known stable ID. Includes archives. Every title and alias in scope is compared, so a complete result covers the whole scope. Optional explicit context IDs require links to ALL of them (one hop, either direction). Returns evidence, candidates, completeness, status and resolution_id. Fuzzy/ambiguous results require clarification or independent identity evidence before writes. 'me' requires an explicitly established self mapping for this local actor. No match is not proof of absence. For create_record resolve its title in the whole target collection.

prepare_writeA

Prepare a concrete write with fresh discovery/resolution evidence. Returns preview and action_id; creates no entities yet. Pass actual clarification/evidence only when needed. Argument shapes (all listed fields required): create_collection: name,purpose,record_meaning,typical_fields(list[str]),relationship_guidance. update_collection: same plus collection_id. Discovery name/purpose must match proposal. add/remove_collection_alias: collection_id,alias; discover alias first; explicit confirmation. create_record: collection_id,title,data; resolve title in whole collection to check duplicates. update_record: record_id,changes,expected_version. archive_record: record_id,expected_version. rename_record: record_id,title,expected_version. add/remove_record_alias: record_id,alias,expected_version (explicit confirmation required). set_self: record_id,expected_version (explicit self identification required). link_records: source_id,relationship_type,target_id (resolve both endpoints). unlink_records: relationship_id (resolve both endpoints from retrieved relationship). Reasons/clarification are agent-reported, not authenticated consent. Do not ask for an additional user approval when identity and intent are already clear. New object IDs in previews are provisional: use the IDs returned by commit_write.

commit_writeA

Commit exactly the prepared action after atomic context revalidation. Tickets expire after 15 minutes; a review goes stale only when something it depends on changes (names in the searched scope, links at its candidates, or the collection catalog). A successful action_id is idempotent on retry, including after restart. Returns durable IDs and audit.

get_collection_historyA

Read paginated collection creation, rename/description, alias and decision history. Includes local actor, UTC timestamps and before/after values. Limit 1–100.

list_collectionsA

Discover collection IDs, normalized names, descriptions and active counts (max 1000).

create_collectionA

Legacy direct write: returns REVIEW_REQUIRED; use prepare_write/commit_write. Create or return the same normalized name (casefold and collapsed whitespace).

search_recordsA

Search active records. text = full-text search over titles AND every stored data value at any depth (not key names): all words must match, case/accent-insensitive, as prefixes ('interv' finds 'interview'); best match first with a match_snippet. Use text when the user describes something by content rather than exact title. query = case-insensitive literal title substring. AND top-level filters use canonical JSON equality (null differs from missing; nested values compare in full). All three combine with AND, as do: where = [{field, op, value}] typed conditions. field is a LIST of keys (["offer","ctc"]), op is eq ne gt gte lt lte between in contains exists missing. A condition matches only when the stored type matches the operand type: 38 never matches "38" or "38 LPA". Dates compare correctly when stored as ISO 8601 strings (2026-10-03). linked_to = {record_id, relationship_types?, direction?}: only records linked to that record; direction is from the matched record's side (outgoing = it is the source). order_by = {field, type: "number"|"string", direction?}: sort by a field; records lacking the field or holding another type are EXCLUDED, not sorted last. Not combinable with text. Return 1–100 bounded previews with an opaque cursor. Zero matches does not establish nonexistence. Reuse the same search parameters with the next cursor.

aggregateA

Count and total active records on the server instead of paging and adding by hand. Filters are the same as search_records (collection_id, where, filters, text, linked_to). metrics = [{op: count}] or [{op: sum|avg|min|max, field: [keys], type?}]; min/max accept type "string" for ISO dates. group_by = {field: [keys], bucket?: "month"|"year"} or {collection: true} or {linked: {relationship_types?, direction?}} (e.g. spend per vendor). ALWAYS read used, skipped_missing and skipped_non_numeric on each metric before quoting a total: a value stored as "95 LPA" or left blank is skipped, not counted as zero, so say how many records the figure leaves out. With linked grouping a record linked to several records counts in each group, so groups can sum to more than matched. Up to 100 groups, largest first; groups_truncated reports more.

get_record_contextA

Get record/version, one-hop incoming/outgoing links and recent events, including archived records. Limits 1–100; event_limit=0 omits history explicitly. Relationship limit applies per direction. Truncation flags indicate omitted results. Follow a returned ID explicitly for another hop.

traverseA

Walk explicit links breadth-first up to max_depth (1–4) hops from one record in a single call, e.g. person -> applications -> openings/interviews -> feedback. Returns each reached record's preview, depth and shortest path (relationship types, directions and titles), plus the relationships walked. relationship_types restricts which exact link types are followed; collection_id filters which records are returned without blocking routes through other collections. max_nodes 1–200 caps reached records; truncated flags mean limits were hit. Includes archived records. Reading does not authorize writes: resolve records before mutating them.

create_recordA

Legacy direct write: returns REVIEW_REQUIRED; use prepare_write/commit_write. Create a generic JSON-object record and audit event. Search first; names are not unique. Returns a stable UUID, version and trusted configured local actor.

update_recordA

Legacy direct write: returns REVIEW_REQUIRED; use prepare_write/commit_write. Shallow-merge top-level data fields: omitted keys remain, null is stored. Supply the retrieved version; VERSION_CONFLICT requires fresh context, never a blind retry.

link_recordsA

Legacy direct write: returns REVIEW_REQUIRED; use prepare_write/commit_write. Create a directed typed link between active records in this workspace, or return the existing triple. Only explicit contextual evidence justifies a link. Audit on source.

unlink_recordsA

Legacy direct write: returns REVIEW_REQUIRED; use prepare_write/commit_write. Remove a wrong link by its own ID; preserve full relationship details in source history.

get_record_historyA

Read 1–100 newest-first audit events, with timestamps, local actor and before/after snapshots; available after archive. Pass next_cursor to continue to older events.

archive_recordA

Legacy direct write: returns REVIEW_REQUIRED; use prepare_write/commit_write. Soft-delete using the retrieved version; increment version and retain audit history and existing links. Archived records are excluded from ordinary search.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 23 tools

Disambiguation5/5

Each tool has a clearly distinct role: reads (search, resolve, traverse, aggregate, history), writes (prepare/commit), batch operations, and import. Although legacy direct-write tools overlap with the prepare/commit workflow, they are explicitly marked as legacy and direct agents to the new flow, eliminating ambiguity.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (create_record, search_records, get_record_history), but a few break the pattern with noun-first names like batch_read and batch_resolve_records, and aggregate stands alone as a bare verb. Minor deviation, still readable.

Tool Count4/5

23 tools is on the higher side, but the scope is broad: collections, records, links, two-phase commits, batch operations, import, search, and audit. Six legacy tools duplicate the prepare/commit surface, adding weight, but the core tool set is still well-scoped for the domain.

Completeness5/5

The surface covers the full lifecycle: collection discovery and creation, record create/read/update/archive, linking/unlinking, resolution, search, aggregation, graph traversal, history, and atomic batch/import operations. The only apparent absence is permanent deletion, which seems intentional in an audit-focused system.

Maintenance

ActivityMaintained
ResponsivenessNo issues