Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
BILINC_API_KEYYesBilinc Cloud API key (bil_live_...). Create one in the Bilinc Cloud dashboard at https://bilinc.space after starting the 7-day trial.

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
commit_memA

Write a memory entry to hosted Bilinc Cloud.

    Creates the entry if it is new and revises it if the key already
    exists. Returns an opaque entry version you can pass to `revise` or
    `forget` as `expected_version` for optimistic concurrency.

    Pass `idempotency_key` when retrying: the same key with the same
    payload returns the original result instead of writing twice.
    
recallA

Retrieve memories from hosted Bilinc Cloud.

    `profile` selects retrieval quality and cost: fast, balanced,
    verified, or deep. Higher profiles do more reflection and return more
    provenance, and are gated by the workspace plan — call `status` to see
    which profiles this key may use. Smart retrieval is this argument, not
    a separate tool.
    
reviseA

Deliberately replace an existing memory, preserving belief revision.

    Use this instead of `commit_mem` when you intend to correct or
    supersede something you already know, so the change is recorded as a
    revision rather than an accidental overwrite.

    Fails with `memory_not_found` if the key does not exist: revise never
    creates. Pass `expected_version` from a previous write to fail with
    `version_conflict` instead of clobbering a concurrent change.
    
forgetA

Remove a memory from active recall. DESTRUCTIVE.

    This is a destructive operation: the entry stops influencing every
    future recall in this project. `reason` is required and is written to
    the audit trail. The deleted value is never returned.

    Use this for state that is genuinely obsolete. To correct a memory
    rather than remove it, use `revise`.
    
statusA

Report the authenticated Bilinc Cloud workspace, plan, and capabilities.

Read-only and never billed. Use this to discover which lifecycle operations and recall profiles the current API key may use before attempting them. Secrets are never returned.

snapshotA

Create or list project checkpoints.

    Take a checkpoint with `action="create"` before risky work so you can
    inspect or restore it later; `action="list"` returns existing
    checkpoints newest first and is free. Neither returns the checkpoint's
    contents.
    
diffA

Compare a checkpoint against another checkpoint or current state.

    Read-only and free. Leave `to_snapshot_id` empty to see what has
    changed since the checkpoint was taken. Values are redacted unless
    `include_values` is set; a value-bearing diff that would be too large
    is refused rather than silently truncated.
    
rollbackA

Restore the project to a checkpoint. DESTRUCTIVE in execute mode.

    Two stages, and you must run them in order:

    1. `mode="preview"` is free and changes nothing. It reports what would
       be created, updated, and removed, and returns a short-lived
       `confirmation_token`.
    2. `mode="execute"` requires that token and permanently discards every
       memory created or changed since the checkpoint.

    Execute fails with `state_changed_since_preview` if the project
    changed after the preview, so review the preview and act on it
    promptly rather than reusing an old one. `reason` is required in both
    modes and is written to the audit trail.
    
list_memoriesA

List the memories stored in this Bilinc Cloud project, ordered by key.

    Read-only and free. Filters: key `prefix`, `memory_type`, and ISO-8601
    `updated_after` / `updated_before`. Returns up to `limit` entries
    (1-100) with key, type, importance, source, created and updated times,
    entry version, and a value whose size follows `values` ("preview" by
    default, "full", or "none"). `total` counts all matches; `nextCursor`
    is the `cursor` for the next page and is null on the last page.
    
historyA

Show the recorded changes to one memory key, newest first.

    Read-only and free. Each entry has the operation (create, update,
    confirm, forget or delete), its time, the recorded reason and source,
    and the value before and after unless `values` is "none". A change
    made by a rollback keeps its create, update or delete operation and
    also carries `rollbackSnapshotId`.
    Values recorded before a memory was forgotten are not returned.
    `exists` is false when the key is not currently stored.
    
confirmA

Record that an existing memory is still accurate.

    The stored value is not changed; the memory's updated time moves to now
    and its history gains a confirm entry. Costs one write operation.
    Fails with `memory_not_found` when the key does not exist, and with
    `version_conflict` when `expected_version` no longer matches.
    

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 11 tools

Disambiguation4/5

Most tools have clearly distinct purposes: recall vs list_memories, diff vs history, and snapshot vs rollback are unambiguous. The main overlap is commit_mem vs revise, both updating existing keys, though the descriptions explicitly guide when to use revise instead of commit_mem.

Naming Consistency3/5

Names mix single verbs (diff, confirm, forget), nouns (history, snapshot, status), and two snake_case verb_noun forms (list_memories, commit_mem). The set remains readable, but there is no consistent naming convention.

Tool Count5/5

11 tools is well-scoped for a memory and checkpoint service. Each tool earns its place, with no obvious bloat or missing essential operation.

Completeness5/5

The surface covers the full memory lifecycle (create, read, update, confirm, forget), version history, checkpointing (snapshot, diff, rollback), and workspace discovery (status). No critical gaps are apparent.

Maintenance

ActivityActive
ResponsivenessNo issues