Bilinc
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BILINC_API_KEY | Yes | Bilinc 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
| 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 |
|---|---|
| commit_memA | Write a memory entry to hosted Bilinc Cloud. |
| recallA | Retrieve memories from hosted Bilinc Cloud. |
| reviseA | Deliberately replace an existing memory, preserving belief revision. |
| forgetA | Remove a memory from active recall. DESTRUCTIVE. |
| 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. |
| diffA | Compare a checkpoint against another checkpoint or current state. |
| rollbackA | Restore the project to a checkpoint. DESTRUCTIVE in execute mode. |
| list_memoriesA | List the memories stored in this Bilinc Cloud project, ordered by key. |
| historyA | Show the recorded changes to one memory key, newest first. |
| confirmA | Record that an existing memory is still accurate. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
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.
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.
11 tools is well-scoped for a memory and checkpoint service. Each tool earns its place, with no obvious bloat or missing essential operation.
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.