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.

    With `purge=true` the memory's stored values are also removed from the
    audit trail and every checkpoint of the project (removal from storage
    and history; key names and value hashes remain). It also works on a
    memory forgotten earlier and cannot be undone. Only purge when the user
    asks for the content to be gone, not just out of recall.

    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. `limit` (1-500) caps the
    preview list; ignored in execute mode.
    
list_memoriesA

List the memories stored in this Bilinc Cloud project.

    Read-only and free. Filters: key `prefix`, `memory_type`, ISO-8601
    `updated_after` / `updated_before`, and `sources` (exact "saved by"
    values). `order` is "key" (default), "newest" (most recently updated
    first) or "oldest"; pass the same order with a `cursor`. 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/5.0

Scored across 11 tools

Disambiguation4/5

Each tool has a clearly stated role, and the descriptions actively disambiguate the risky pairs (commit_mem vs revise, forget vs revise, recall vs list_memories). A few boundaries still blur — recall vs list_memories are both reads over stored memories, and diff vs history both inspect change — but the docs give explicit guidance on when to use which.

Naming Consistency3/5

All names are snake_case and readable, but the convention is mixed: some are bare verbs (commit_mem, recall, revise, forget, confirm), some are bare nouns (status, snapshot, history, diff), and one uses a verb_noun form (list_memories). Not chaotic, but no single predictable pattern an agent can rely on.

Tool Count5/5

Eleven tools is well within the sweet spot and every one earns its place: write, read, revise, forget, confirm, inspect, checkpoint, restore, and capability discovery. No filler or near-duplicate tools.

Completeness4/5

The memory lifecycle is essentially fully covered — create, retrieve, list, revise, confirm, forget/purge, audit history, plus checkpoint/diff/rollback and status discovery. Minor gaps remain: no bulk/batch operations, no tag or source management, and no export path for migrating memories out.

Maintenance

ActivityActive
ResponsivenessNo recent community issues