What can you do with this server?

The Bilinc server provides hosted memory infrastructure for coding agents, enabling durable state management with provenance. It offers three MCP tools: * commit_mem: Write a memory entry with a unique key and value, optional metadata (key-value object), importance (numeric, default 1), and memory_type (default "semantic"). Each write carries provenance. * recall: Retrieve prior memories using a natural language query, with optional limit (default 10) and retrieval profile (default "balanced"). * status: Check the health and account state of your hosted Bilinc Cloud instance.

Bilinc

by atakanelik34

Overview Schema Related Servers Score Discussions

Python

Remote

Bilinc

PyPI Python License MCP Release

Hosted memory infrastructure for AI agents: commit, recall, and inspect agent state through one API key, with verification, provenance, and recovery around every write.

Retrieval answers "what is similar to this?". Long-running agents also need to answer "who wrote this state, was it verified, did it contradict what we already knew, and can we undo it?" — that is the layer Bilinc provides.

Bilinc 2.2.0 on PyPI is the public cloud-only package: a thin Python SDK, CLI, and MCP adapter for Bilinc Cloud. It does not ship the local StatePlane, storage backends, eval, observability, integrations, or server runtime internals.

Frozen regression receipt — LongMemEval-s cleaned retrieval fixture, 500 questions: Hit@5 98.0%, NDCG@5 0.913, no LLM reranker, no paid API. This is an isolated retrieval guardrail, not a current hosted SLA, end-to-end agent score, or competitor ranking — see Benchmark receipt for the full scope and qualification.

The short version

Bilinc is the state layer between an agent and the things it must remember. It keeps memory writes attributable, correctable, and recoverable instead of treating retrieval as a bag of similar text.

If your agent needs to...	Bilinc gives it...
Recall a decision before acting	Key-scoped recall with explicit profiles and evidence metadata
Correct a bad memory	`revise`, contradiction-aware state, and provenance-preserving updates
Recover from an unsafe run	Snapshots, diffs, and confirmed rollback
Work across any MCP-compatible agent	A Python SDK, CLI, and stdio MCP adapter

The fastest path is pip install -U bilinc, bilinc login, then bilinc quicktest against Bilinc Cloud.

Related MCP server: inspeximus

Use Bilinc when

A long-running agent — coding, support, research, or a personal assistant — needs to recall prior decisions before a risky action.
You need to know which run, tool, or operator produced a piece of agent state.
A bad agent run wrote incorrect state and you need a recovery path, not a manual cleanup.
Several agents or teammates share one memory surface and you need key-scoped access and usage visibility.

Do not use Bilinc when

You only need semantic search over documents — a vector database is the simpler primitive.
You require an Apache-2.0 licensed, fully self-hosted runtime. The public package is cloud-only and licensed BUSL-1.1.
You want the memory layer to also be your agent framework. Bilinc is the state layer your runtime calls; it does not orchestrate agents.

Choose your surface

You want...	Use...
A hosted memory API for an agent or MCP client	The public cloud-only package from PyPI
Local StatePlane, SQLite/PostgreSQL, benchmarks, or internals	This repository and the architecture guide
A hosted MCP connection	The MCP setup guide

The public package is intentionally smaller than this repository. It does not bundle the internal StatePlane or local storage runtime.

Start in 60 Seconds

pip install -U bilinc
bilinc start

bilinc start is the first-run guide. The activation target is simple: reach a passing bilinc quicktest, which performs one hosted commit, one hosted recall, and one Cloud status check.

Start the 7-day Bilinc Cloud trial at https://bilinc.space/signup.
Confirm email.
Create one hosted API key in the Cloud dashboard.
Connect the CLI:

bilinc login --api-key bil_live_...
bilinc quicktest

To reproduce this release exactly:

pip install -U bilinc==2.2.0

If you prefer a browser guide, open https://bilinc.space/install and follow the same four-step path.

MCP Adapter

Bilinc exposes a standard Model Context Protocol server over stdio, so any MCP-compatible client can connect — Claude Code, Codex, Cursor, Hermes-Agent, opencode, and others.

{
  "mcpServers": {
    "bilinc": {
      "command": "python",
      "args": ["-m", "bilinc.cloud_mcp"],
      "env": { "BILINC_API_KEY": "bil_live_..." }
    }
  }
}

Eight tools — the core memory lifecycle, and nothing else:

Tool	What it does
`commit_mem`	Write durable agent state. Each write carries provenance — which run, tool, or operator produced it — and returns a version for optimistic concurrency.
`recall`	Retrieve prior context and decisions before acting. `profile` selects retrieval quality; smart retrieval is that argument, not a separate tool.
`revise`	Deliberately correct something already known. It never creates, so a correction stays distinguishable from an accidental overwrite.
`forget`	Destructive. Remove obsolete state from active recall. A reason is required and is audited; the deleted value is never returned.
`status`	Report the authenticated workspace, plan, capabilities, recall profiles, limits, and usage. Never billed.
`snapshot`	Checkpoint a project before risky work, or list existing checkpoints.
`diff`	Compare a checkpoint against another checkpoint or current state. Values are redacted by default.
`rollback`	Destructive in execute mode. Restore a checkpoint through a free preview plus an explicitly confirmed execute.

Operator and debug tooling — health probes, benchmarks, export/import, workspace replay — stays local-only, as do the epistemic read tools for claims, contradictions, and graph queries. The hosted adapter does not bundle local runtime internals.

Documented client setups: Claude Code · Codex · Cursor · any MCP client

Python SDK

from bilinc import CloudClient

client = CloudClient()  # reads BILINC_API_KEY or a key saved by `bilinc login`

# Write, and keep the version for optimistic concurrency.
written = client.commit("agent.goal", {"ship": "reliable memory"}, memory_type="semantic")
results = client.recall("agent goal", limit=5)

# Correct something you already know. Fails if it does not exist.
client.revise("agent.goal", {"ship": "verifiable memory"},
              reason="scope corrected", expected_version=written["entryVersion"])

# Checkpoint before risky work, then see what changed.
snapshot = client.create_snapshot(label="before-autonomous-run")["snapshot"]
client.diff(snapshot["id"])

# Drop obsolete state. A reason is required and is audited.
client.forget("agent.goal", reason="superseded by the planner service")

# Recover. Preview is free; execute is destructive and needs the token.
preview = client.rollback_preview(snapshot["id"], reason="undo bad agent run")
client.rollback(snapshot["id"], confirmation_token=preview["confirmationToken"],
                reason="undo bad agent run")

client.status()   # what can this key do?
client.health()   # is the service reachable?

For server, CI, and hosted agent runtimes, store the key as BILINC_API_KEY.

CLI

bilinc status                 # authenticated plan, capabilities, limits, usage
bilinc health                 # public service health
bilinc commit --key agent.goal --value '{"ship":"reliable memory"}'
bilinc recall --query "agent goal"
bilinc revise --key agent.goal --value '{"ship":"verifiable memory"}' --reason "scope corrected"
bilinc snapshot create --label before-autonomous-run
bilinc snapshot list
bilinc diff --from-snapshot snap_...
bilinc forget --key agent.goal --reason "superseded by the planner service"
bilinc doctor

Rollback is two stages. Execute takes the token from the preview and never prompts interactively, so it stays safe inside automation:

bilinc rollback preview --snapshot snap_... --reason "undo bad agent run"
bilinc rollback execute --snapshot snap_... --reason "undo bad agent run" \
  --confirmation-token <token-from-preview>

Useful first-run commands:

bilinc start
bilinc login --api-key bil_live_...
bilinc quicktest
bilinc mcp install

Hosted Endpoints

Endpoint	Notes
`GET /api/cloud/health`	Public service health. No key, no billing.
`GET /api/cloud/status`	Authenticated capabilities for one key. Never billed.
`POST /api/cloud/memory/commit`	Write.
`POST /api/cloud/memory/recall`	Read.
`POST /api/cloud/memory/revise`	Replace an existing memory.
`POST /api/cloud/memory/forget`	Destructive. Reason required.
`GET /api/cloud/memory/snapshots`	List checkpoints. Free.
`POST /api/cloud/memory/snapshots`	Create a checkpoint.
`POST /api/cloud/memory/diff`	Compare checkpoints. Free.
`POST /api/cloud/memory/rollback/preview`	Free. Mints a confirmation token.
`POST /api/cloud/memory/rollback`	Destructive. Requires that token.

All hosted endpoints share https://bilinc.space. Authenticated memory operations require an active Bilinc Cloud entitlement.

Send an Idempotency-Key header on any write you might retry: the same key with the same payload replays the original result and is billed once, and the same key with a different payload is refused with 409 idempotency_conflict.

Benchmark receipt

Frozen regression receipt, LongMemEval-s cleaned retrieval fixture, 500 questions: Hit@5 98.0%, NDCG@5 0.913, with no LLM reranker and no paid API.

This is a frozen isolated retrieval guardrail — not a current hosted SLA, not an end-to-end agent score, and not a competitor ranking. Published memory-system scores use different metrics, datasets, and levels of LLM assistance, so they are not directly comparable. Present this receipt only with this isolated scope attached.

Evidence map

The repository keeps dated manifests with source state, dataset provenance, runner and metric semantics. These are traceability artifacts, not claims that Bilinc is universally first place.

Lane	Publicly stored evidence	Scope
LongMemEval-s	frozen manifest	Isolated retrieval guardrail
AMB legacy v3	current Modal manifests	Historical generic harness; not Vectorize AMB RAG/judge
Official LoCoMo	retrieval manifests	Retrieval component; not end-to-end QA/F1
Evidence contract	validation rules	Hashes, limitations, and reproducibility boundaries

For the engineering rationale, read Why vector search is not enough for agent memory.

Compare

Answer guides

Contributing

Start with CONTRIBUTING.md. Use Discussions for design questions and roadmap feedback; use an issue for a reproducible bug or a scoped implementation task.

Security reports should follow SECURITY.md. Please do not include private memory values, API keys, or production logs in issues, pull requests, benchmark fixtures, or screenshots.

License

BUSL-1.1. See LICENSE.

Available Tools

8 tools

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.

ParametersJSON Schema

Name	Required	Default
`key`	Yes
`ttl`	No
`value`	Yes
`source`	No
`metadata`	No
`priority`	No
`canonical`	No
`importance`	No
`session_id`	No
`memory_type`	No	semantic
`idempotency_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses key behaviors: upsert semantics, returning an opaque version for optimistic concurrency, and idempotent behavior via `idempotency_key`. These are important beyond what annotations would provide. It doesn't mention failure modes or limitations, but the disclosed traits are significant and clearly described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, with the main purpose stated first. It uses three short paragraphs that each add value: purpose, upsert/version behavior, and idempotency. It is not overly verbose, though it could be slightly tighter by merging related thoughts. Overall, it is well-structured and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (11 parameters, 0% schema coverage, no annotations), the description is incomplete. It covers the core upsert and idempotency behavior but leaves many parameters unexplained, which could lead an agent to misuse the tool. The presence of an output schema helps with return values, but the input side is under-documented. A more comprehensive description should at least summarize the role of key parameters like `memory_type`, `priority`, and `ttl`.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only explains `idempotency_key` in detail; the other 10 parameters (e.g., `key`, `value`, `ttl`, `priority`, `metadata`, `memory_type`) are not elaborated. The description does not clarify what `value` should be, how `memory_type` affects behavior, or the meaning of fields like `canonical` and `importance`. This is a significant gap for a tool with 11 parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Write a memory entry to hosted Bilinc Cloud.' It further explains the upsert behavior ('Creates the entry if it is new and revises it if the key already exists'), which distinguishes it from siblings like `revise` and `recall`. This is a specific verb+resource with differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives context by explaining that the returned version can be passed to `revise` or `forget`, implying when those tools are appropriate. It also explains idempotency usage for retries. However, it does not explicitly state when NOT to use this tool or name alternatives for read/delete scenarios, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`include_values`	No
`to_snapshot_id`	No
`from_snapshot_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses that the operation is read-only and free, values are redacted unless include_values is set, and overly large diffs are refused rather than silently truncated. This gives the agent important behavioral expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with the main purpose in the first line and additional key behaviors following. Every sentence adds value, and it is not padded with fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers essential behavioral context: read-only, free, redaction behavior, and refusal of large diffs. The output schema exists, so return format need not be detailed. However, it does not mention the limit parameter or edge cases, which would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the semantics of to_snapshot_id (optional, defaults to current state) and include_values (controls value redaction), but does not explain limit or from_snapshot_id in detail. This partial coverage earns a 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the primary action: 'Compare a checkpoint against another checkpoint or current state.' This uses a specific verb ('Compare') and resource ('checkpoint'), and the mention of 'current state' distinguishes it from sibling tools like snapshot or rollback.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for when to use the tool: to compare checkpoints or see changes since a checkpoint. It also explains the key behavior of leaving to_snapshot_id empty. However, it does not explicitly mention alternatives or when not to use it, which keeps it from a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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`.

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes
`reason`	Yes
`idempotency_key`	No
`expected_version`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It clearly discloses the destructive nature, that the entry stops influencing future recall, that `reason` goes to the audit trail, and that the deleted value is never returned. This is thorough behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, with a bold DESTRUCTIVE warning and short paragraphs. Every sentence earns its place, front-loading the purpose and then adding necessary details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers essential aspects: destructive behavior, audit trail, and the alternative tool. An output schema exists, so return values need not be explained. It leaves out edge-case behavior (e.g., key not found) but overall is complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It adds meaning for `reason` (required, audit trail) and implicitly clarifies `key` (the memory to remove). However, it says nothing about `idempotency_key` or `expected_version` beyond their schema defaults. Partial compensation, adequate but with gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Remove a memory from active recall' with a specific verb and resource. It also distinguishes itself from the sibling tool `revise` by explicitly saying 'To correct a memory rather than remove it, use revise.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Use this for state that is genuinely obsolete.' It also names an alternative (`revise`) and explains when not to use it (when correcting rather than removing), satisfying the when/when-not/alternatives criterion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	Yes
`explain`	No
`profile`	No	balanced
`memory_types`	No
`query_timestamp`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description takes on the burden of explaining behavior. It discloses that higher profiles 'do more reflection and return more provenance' and are 'gated by the workspace plan,' which is valuable context. It also mentions cost implications. However, it does not explicitly state whether recall is read-only or describe other side effects, leaving some ambiguity for a no-annotation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary purpose. Each sentence earns its place: the first states the core action, and the second explains the profile parameter's nuances and its relationship to the status tool. There is no redundant fluff or repetition of schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, one required), the description covers only the retrieval purpose and profile specifics. The output schema exists and can explain return values, but the description does not clarify other parameters or edge cases. It is adequate for a basic retrieval tool but feels incomplete for an agent needing to use memory_types, query_timestamp, or explain effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter meaning. It only explains the 'profile' parameter in detail, covering just one of six parameters. The description does not address query, limit, explain, memory_types, or query_timestamp, leaving the agent without sufficient guidance for these parameters despite their self-explanatory names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Retrieve memories from hosted Bilinc Cloud.' It clearly distinguishes from siblings like commit_mem, revise, and forget by focusing on retrieval. The additional note that 'Smart retrieval is this argument, not a separate tool' further disambiguates from potential alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides practical guidance: 'call `status` to see which profiles this key may use' indicates a prerequisite for using higher profiles. It also clarifies that profile-based retrieval is not a separate tool. However, it does not explicitly state when to use recall vs. other memory operations or list exclusions, so it misses some explicit alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Default
`key`	Yes
`value`	Yes
`reason`	No
`strategy`	No	entrenchment
`importance`	No
`idempotency_key`	No
`expected_version`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the disclosure burden. It reveals important behaviors: never creates, fails with memory_not_found, supports expected_version for concurrency (version_conflict). It does not mention auth or reversibility, but for a memory tool these are less critical. Slightly incomplete but strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each adding substantive value: purpose, alternative differentiation, failure mode, concurrency behavior. No filler or repetition, well front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters and zero schema descriptions, the description is too thin. It covers core use cases and error scenarios, but omits guidance on the optional parameters and does not describe the response shape (though an output schema exists). It is minimally adequate but has clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only explains `expected_version` and implies `key` must exist, but does not clarify the meaning or usage of `value`, `reason`, `strategy`, `importance`, or `idempotency_key`. This leaves most parameters under-specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Deliberately replace an existing memory.' It clearly distinguishes the tool from siblings by stating it is for corrections/superseding rather than creating, which aligns with the sibling context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use this instead of `commit_mem` when correcting or superseding existing knowledge, and notes that it never creates (fails with memory_not_found). This provides clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Default
`mode`	No	preview
`reason`	Yes
`snapshot_id`	Yes
`idempotency_key`	No
`confirmation_token`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the burden of behavioral disclosure. It explicitly warns 'DESTRUCTIVE in execute mode,' explains that preview changes nothing, requires a confirmation token for execute, permanently discards memories, and mentions the failure mode `state_changed_since_preview` and audit trail writing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear summary, numbered steps, and a note on failure handling. It is somewhat long but each sentence adds necessary value for a destructive two-stage tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, no annotations, output schema present), the description is complete. It covers the full workflow, danger, token requirement, failure condition, and audit trail without needing to explain return values due to the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the semantics of mode, confirmation_token, and reason, and implies snapshot_id as the checkpoint identifier. However, it does not explicitly describe idempotency_key, though it is optional. This is a minor gap given the strong coverage of the critical parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Restore the project to a checkpoint.' This is a specific verb+resource combination that distinguishes it from siblings like snapshot (creating checkpoints) and diff (comparing states).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear procedural context: two stages must run in order (preview then execute), and it explains the requirements for each mode. It doesn't explicitly compare to alternatives or state when not to use the tool, but the workflow guidance is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Default
`label`	No
`limit`	No
`action`	No	create
`metadata`	No
`idempotency_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, but the description discloses key behavior: list is free, ordering is newest-first, and neither action returns checkpoint contents. This adds meaningful context beyond the schema, though it does not cover side effects of creation or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences cover purpose, usage advice, and a behavioral caveat with no redundancy. Information is front-loaded and the description is appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema and a moderate parameter count; the description covers the main workflows. It lacks detail on parameter meanings and restore mechanics, but overall is sufficient for basic usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains the action parameter values (create/list) but does not clarify label, limit, metadata, or idempotency_key. Schema coverage is 0%, so these parameters remain ambiguous despite self-explanatory titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool creates or lists project checkpoints, with specific action values. Differentiates from sibling tools by focusing on checkpoint capture/list rather than memory/commit/rollback operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises using create before risky work, and notes list is free and returns newest first. Does not name alternative tools but provides context for when each action is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool is 'Read-only and never billed' and that 'Secrets are never returned,' which are important safety traits. It does not elaborate on caveats like rate limits, but the disclosed traits are strong for a status tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences and every sentence earns its place: the first states the purpose, the second conveys safety and usage, and the third reassures about secrecy. It is front-loaded with the most important information and contains no redundant words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, an output schema is present, and the tool is simple (status report), the description fully covers what an agent needs to know. It states what the tool returns (workspace, plan, capabilities), when to use it, and that it is safe and read-only. The existence of the output schema eliminates the need to describe return formats.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema provides no parameter semantics. Per the rubric, a baseline of 4 is appropriate for 0-parameter tools. The description adds no parameter information because there is nothing to add.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Report the authenticated Bilinc Cloud workspace, plan, and capabilities,' which uses a specific verb and clearly identifies the resource and scope. This distinguishes it from sibling lifecycle tools like commit_mem and forget, which perform mutations. The purpose is unambiguous and immediately understood.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: 'Use this to discover which lifecycle operations and recall profiles the current API key may use before attempting them.' This makes the intended use case clear. It does not explicitly exclude other uses or name alternatives, but the context is sufficient for an agent to know when to call this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

1 tool updatev2.1.9Aug 8, 2026

Changedrecall1 field changed

addedInput schema / properties / query_timestamp

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Query Timestamp"
+}

7 tool updatesv2.1.6Jul 31, 2026

Changedcommit_mem6 fields changed

addedInput schema / properties / canonical

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Canonical"
+}

addedInput schema / properties / idempotency_key

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Idempotency Key"
+}

addedInput schema / properties / priority

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Priority"
+}

addedInput schema / properties / session_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Session Id"
+}

addedInput schema / properties / source

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Source"
+}

addedInput schema / properties / ttl

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Ttl"
+}

Addeddiff
Addedforget

Changedrecall2 fields changed

addedInput schema / properties / explain

Added value: +{
+  "default": false,
+  "title": "Explain",
+  "type": "boolean"
+}

addedInput schema / properties / memory_types

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Memory Types"
+}

Addedrevise
Addedrollback
Addedsnapshot

3 tool updatesv1.0.0Jul 28, 2026
- First observedcommit_mem
- First observedrecall
- First observedstatus

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation4/5

Most tools target distinct operations (recall, status, forget, snapshot, diff, rollback), but commit_mem and revise both perform writes to memory and could be confused. The descriptions clarify the intended use, making the overlap manageable.

Naming Consistency3/5

Tool names mix bare verbs (recall, revise, forget, rollback), nouns (status, snapshot, diff), and a compound (commit_mem). There is no consistent verb_noun pattern, though each name is clear and readable.

Tool Count5/5

Eight tools is well within the ideal range for a memory/checkpoint server. Each tool addresses a necessary part of the lifecycle without unnecessary redundancy.

Completeness4/5

The toolset covers memory creation, retrieval, revision, deletion, plus checkpoint operations and status. A dedicated list/search tool is absent, but recall likely handles retrieval, so the surface is nearly complete for its purpose.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

memnodeOAuth
dev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Knowledge & Memory Autonomous Agents Agent Orchestration
2
TeamShared B
io.github.xhad
Shared memory for coding agents. Stop re-explaining your codebase every session.
Knowledge & Memory Developer Tools
1221
ContextLattice
io.github.sheawinkler
Private-by-default, local-first memory/context/task orchestrator for MCP apps and agents.
Knowledge & Memory Agent Orchestration Autonomous Agents
2153
Synap Memory A
ai.maximem
Persistent memory for AI agents — log and recall conversation context over MCP.
Knowledge & Memory AI & Machine Learning
4248

Related MCP Servers

mem-universe
Knowledge & Memory Search
H1an1
A
license
A
quality
C
maintenance
Self-hosted MCP memory server that gives a multi-agent fleet one shared, git-backed memory for search, read, and write.
Updated 2 months ago (2026-06-27 08:20 UTC)
8
1
MIT
inspeximus
Autonomous Agents Knowledge & Memory
DanceNitra
A
license
A
quality
A
maintenance
mnemo — an MCP server for agent memory with a first-class correction & erasure channel (revert, lineage-aware retraction, tamper-evident deletion receipts). Zero dependencies, 12 tools over stdio
Updated 10 hours ago (2026-09-06 18:52 UTC)
73
6
MIT
GoodMemory
RAG Systems Knowledge & Memory Coding Agents
hjqcan
A
license
B
quality
A
maintenance
Local-first, auditable memory for Codex, Claude Code, and MCP clients. It stores scoped user/project memory in SQLite or Postgres, serves read-only recall and inspection tools by default, and supports opt-in governed writeback with review and forget controls.
Updated 4 days ago (2026-09-03 10:51 UTC)
8
262
17
MIT
RepoRecall
Knowledge & Memory RAG Systems
esannkv
A
license
Not graded
quality
B
maintenance
Provides persistent, local-first memory for coding agents with Markdown as the source of truth, exposed via CLI, loopback API, MCP, and Codex hooks for context retrieval and durable writes.
Updated 15 days ago (2026-08-23 11:20 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/atakanelik34/Bilinc'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Bilinc

The short version

Use Bilinc when

Do not use Bilinc when

Choose your surface

Start in 60 Seconds

MCP Adapter

Python SDK

CLI

Hosted Endpoints

Benchmark receipt

Evidence map

Compare

Answer guides

Contributing

Links

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API