Skip to main content
Glama
deenesjakoruzh
AlekseiMarchenko

Central Intelligence

by AlekseiMarchenko
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

Central Intelligence

Agents forget. CI remembers.

Persistent memory for AI agents. Store, recall, and share information across sessions. Works with Claude Code, Cursor, LangChain, CrewAI, and any agent that supports MCP.

CI never rewrites your memories. Facts are extracted for search, but your content is always returned verbatim. No junk memories, no hallucinated rewrites, no data loss.

npm License: Apache 2.0

Central Intelligence MCP server

LifeBench 52.2% LongMemEval 75.0% AMB 90/100

Quick Start (30 seconds)

# One command — gets API key + auto-configures your AI tools
npx central-intelligence-local signup

# Done. Your agent now has persistent memory.
# Restart Claude Code / Cursor / Windsurf to activate.

Or run locally with no cloud:

npm i -g central-intelligence-local && ci dashboard
# Installs and opens the dashboard at localhost:3141

Related MCP server: mcp-memory

When to Use Central Intelligence

Heuristic: If you would write it in a note to your future self, store it in Central Intelligence.

Scenario

What to do

Starting a new session, need context from before

recall or context

Discovered something important (architecture, preferences, fixes)

remember

Multiple agents working on the same project

share with user/org scope

You keep re-learning the same things each session

remember once, recall forever

Handing off a task to another agent or session

remember key decisions, next agent calls context

User tells you the same preferences repeatedly

remember them, check with recall next time

Don't store: secrets, passwords, API keys, PII, large binary files, or ephemeral scratch data.

The Problem

Every AI agent session starts from zero. Your agent learns your preferences, understands your codebase, figures out your architecture — then the session ends and it forgets everything. Next session? Same questions. Same mistakes. Same context-building from scratch.

Central Intelligence fixes this.

What It Does

Five MCP tools give your agent a long-term memory:

Tool

Description

Example

remember

Store information for later

"User prefers TypeScript and deploys to Fly.io"

recall

Semantic search across past memories

"What does the user prefer?"

context

Auto-load relevant memories for the current task

"Working on the auth system refactor"

forget

Delete outdated or incorrect memories

forget("memory_abc123")

share

Make memories available to other agents

scope: "agent" → "org"

Benchmarks

LifeBench (2026) — Long-Term Multi-Source Memory

CI scores 52.2% on LifeBench, the hardest published memory benchmark (2,003 questions across 10 users, 51K real-world events including messages, calendar, health records, notes, and calls).

Overall

Info Extraction

Multi-hop

Temporal

Nondeclarative

52.2%

47.2%

52.9%

46.4%

64.1%

Answer model: gpt-5.4-mini. Judge: gpt-4.1-mini. Evaluation harness: lifebench-eval.

LongMemEval (ICLR 2025) — Conversational Memory

CI scores 75.0% on LongMemEval, testing conversational memory across 500 questions spanning single-session recall, multi-session reasoning, temporal reasoning, knowledge updates, and preference tracking.

Overall

Single-session

Multi-session

Temporal

Preference

75.0%

91.9%

66.2%

69.9%

76.7%

Answer model: gpt-5.4-mini. Judge: gpt-4o. Evaluation harness: lifebench-eval.

Agent Memory Benchmark (AMB) — Infrastructure Testing

Test CI against other providers using the open-source Agent Memory Benchmark:

npx agent-memory-benchmark --provider central-intelligence --api-key $CI_API_KEY

Note: AMB is maintained by the same author as Central Intelligence. Run it yourself and verify the results. PRs with new provider adapters are welcome.

Roadmap

Advanced retrieval — fact extraction, entity graph, multi-hop reasoning, temporal inference, explainability traces — is prototyped in the codebase and coming to Enterprise. Architecture details: v1.0.0 prototype release. Commercial availability: pricing.

Cross-Tool Memory

CI Local reads config files from 5 AI coding platforms and makes them searchable alongside your stored memories:

Platform

Config file

How it's parsed

Claude Code

CLAUDE.md

Section-based (## headings)

Cursor

.cursor/rules

Paragraph-based

Windsurf

.windsurf/rules

Paragraph-based

Codex

codex.md

Section-based

GitHub Copilot

.github/copilot-instructions.md

Section-based

Memories stored via Claude Code are discoverable when using Cursor, and vice versa. Your AI memory works everywhere, not just in one tool.

Recall responses now include source (which tool the memory came from), freshness_score (how recent), and duplicate_group (near-duplicate detection across tools).

How It Works

Agent (Claude, Cursor, Windsurf, Copilot, Codex)
    ↓ MCP protocol
Central Intelligence MCP Server (local, thin client)
    ↓
SQLite + vector embeddings + config file parsing
    ↓
Hybrid search: vector + FTS5 + fuzzy + temporal decay
    ↓
Central Intelligence API (hosted)
    ↓
PostgreSQL + pgvector + fact decomposition + entity graph
    ↓
4-way retrieval: vector + BM25 + graph traversal + temporal
    ↓
Local ONNX cross-encoder reranker (zero API cost)

Every memory is decomposed into structured facts with entities, temporal info, and causal relations. Recall runs a dual-path architecture: both fact-based 4-way search (vector, BM25, graph traversal, temporal) and memory-based 2-way search run in parallel. A query type classifier routes each question to the best retrieval path, and results are fused with Reciprocal Rank Fusion and reranked with a local cross-encoder model. Config files from all supported platforms are parsed, embedded, and cached locally.

Memory Scopes

Scope

Visible to

Use case

agent

Only the agent that stored it

Personal context, session continuity

user

All agents serving the same user

User preferences, cross-tool context

org

All agents in the organization

Shared knowledge, team decisions

MCP Server Setup

Claude Code

Add to ~/.claude/settings.json under mcpServers:

{
  "central-intelligence": {
    "command": "npx",
    "args": ["-y", "central-intelligence-mcp"],
    "env": {
      "CI_API_KEY": "your-api-key"
    }
  }
}

Cursor

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "central-intelligence": {
      "command": "npx",
      "args": ["-y", "central-intelligence-mcp"],
      "env": {
        "CI_API_KEY": "your-api-key"
      }
    }
  }
}

Any MCP-Compatible Client

The MCP server is published as central-intelligence-mcp on npm. Point your MCP client to it with the CI_API_KEY environment variable set.

CLI Usage

# Install globally
npm install -g central-intelligence-local

# Get API key + auto-configure AI tools
ci signup

# Open local memory dashboard
ci dashboard

# Sync local memories to cloud
ci sync

# Audit memory health (duplicates, staleness, health score)
ci audit

# Import from ChatGPT data export
ci chatgpt-import conversations.json

# Export/import memory bundles
ci export -o memories.json
ci import memories.json

REST API

Base URL: https://central-intelligence-api.fly.dev

All endpoints require Authorization: Bearer <api-key> header.

Create API Key

curl -X POST https://central-intelligence-api.fly.dev/keys \
  -H "Content-Type: application/json" \
  -d '{"name": "my-key"}'

POST /memories/remember

{
  "agent_id": "my-agent",
  "content": "User prefers TypeScript over Python",
  "tags": ["preference", "language"],
  "scope": "agent"
}

POST /memories/recall

{
  "agent_id": "my-agent",
  "query": "what programming language does the user prefer?",
  "limit": 5
}

Response:

{
  "memories": [
    {
      "id": "uuid",
      "content": "User prefers TypeScript over Python",
      "relevance_score": 0.434,
      "tags": ["preference", "language"],
      "scope": "agent",
      "created_at": "2026-03-22T21:42:34.590Z"
    }
  ]
}

POST /memories/context

{
  "agent_id": "my-agent",
  "current_context": "Setting up a new web project for the user",
  "max_memories": 5
}

DELETE /memories/:id

POST /memories/:id/share

{
  "target_scope": "org"
}

GET /usage

Returns memory counts, usage events, and active agents for the authenticated API key.

Self-Hosting

# Clone and install
git clone https://github.com/AlekseiMarchenko/central-intelligence.git
cd central-intelligence
npm install

# Set up PostgreSQL
createdb central_intelligence
psql -d central_intelligence -f packages/api/src/db/schema.sql

# Configure
cp .env.example .env
# Edit .env: set DATABASE_URL and OPENAI_API_KEY

# Run
npm run dev:api

Deploy to Fly.io

fly apps create my-ci-api
fly postgres create --name my-ci-db
fly postgres attach my-ci-db
fly secrets set OPENAI_API_KEY=sk-...
fly deploy

Then point the MCP server to your instance:

{
  "env": {
    "CI_API_KEY": "your-key",
    "CI_API_URL": "https://your-app.fly.dev"
  }
}

Architecture

central-intelligence/
├── packages/
│   ├── api/            # Backend API (Hono + PostgreSQL + pgvector)
│   │   ├── src/
│   │   │   ├── db/           # Schema, migrations (facts, entities, pgvector, hybrid)
│   │   │   ├── middleware/   # Auth, rate limiting, billing, x402 payments
│   │   │   ├── routes/       # REST endpoints, dashboard, docs, demo
│   │   │   └── services/     # Core logic:
│   │   │       ├── memories.ts          # Store + v2 hybrid recall (pgvector + BM25 + RRF + reranker)
│   │   │       ├── rerank.ts            # bge-reranker-v2-m3 (local ONNX), Cohere API fallback
│   │   │       ├── embeddings.ts        # OpenAI text-embedding-3-small
│   │   │       ├── encryption.ts        # AES-256-GCM at rest
│   │   │       ├── date-parser.ts       # Temporal extraction from memory content
│   │   │       ├── auth.ts              # API key validation
│   │   │       ├── fact-extraction.ts   # [Enterprise] Structured fact decomposition via GPT-4o-mini
│   │   │       ├── entity-resolution.ts # [Enterprise] Trigram + co-occurrence entity merging
│   │   │       ├── observations.ts      # [Enterprise] Auto-synthesized higher-level facts
│   │   │       └── query-decompose.ts   # [Enterprise] Query expansion via GPT-4o-mini
│   │   └── tests/        # Vitest
│   ├── mcp-server/     # MCP server (npm: central-intelligence-mcp)
│   ├── cli/            # Cloud CLI (npm: central-intelligence-cli, legacy)
│   ├── local/          # Local memory with cross-tool config parsing
│   ├── node-sdk/       # Node.js/TypeScript SDK (npm: central-intelligence-sdk)
│   ├── python-sdk/     # Python SDK (PyPI: central-intelligence)
│   └── openclaw-skill/ # OpenClaw skill file
├── .github/workflows/  # CI (typecheck + test) + Deploy (Fly.io)
├── benchmark/          # LifeBench VM (self-contained Fly machine)
├── db/                 # Custom Postgres image with pgvector baked in
├── landing/            # Landing page
├── Dockerfile          # API container (non-root, ONNX model pre-cached)
├── fly.toml            # Fly.io config (iad region, health checks)
└── README.md

Pricing

Tier

Price

Memories

Agents

Free

$0

500

Unlimited

Pro

$29/mo

50,000

Unlimited

Team

$99/mo

500,000

Unlimited

See centralintelligence.online/#pricing for the latest.

Contributing

Contributions welcome. Open an issue or PR.

License

Apache 2.0

Available Tools

5 tools
contextA

Load relevant memories for the current task, designed for session bootstrapping. This is a read-only operation identical to recall internally, but optimized for broad context loading rather than specific questions. Call context at the start of every conversation, passing a description of what you are working on, to retrieve past decisions, preferences, and project knowledge. Also call when switching topics mid-session. Use context (not recall) for "what do I need to know about X?" and recall for "what specifically was decided about Y?". Returns up to max_memories results ranked by relevance. Costs 1 operation. Returns empty list (not error) if no relevant memories exist.

ParametersJSON Schema
NameRequiredDescriptionDefault
current_contextYesDescription of what you are currently working on. Be specific: 'refactoring the authentication middleware in the Express API' retrieves better context than 'working on auth'. This is the search query for memory retrieval.
agent_idNoAgent instance identifier. Must match the agent_id used when storing memories. Default: 'default'.default
user_idNoUser identifier. When provided, also retrieves user-scoped memories shared by other agents.
max_memoriesNoMaximum memories to return, 1-20. Default 5. Use 10-15 at session start for broad context loading, 3-5 for topic switches.

TDQS

A4.7/5.0
Behavior5/5

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

No annotations provided, but description fully covers behavior: read-only operation, costs 1 operation, returns up to max_memories, empty list if no relevant memories, and internal similarity to recall. No contradictions.

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?

Description is front-loaded with key purpose and usage, then provides additional details. Each sentence adds value, but it could be slightly more concise. Still efficient.

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?

No output schema, but description covers return behavior (up to max_memories, empty list not error). For a read-only retrieval tool with good parameter guidance, this is sufficiently complete.

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 coverage is 100%, so baseline is 3. Description adds value beyond schema: examples for specific context query, usage suggestions for max_memories (e.g., 10-15 at start).

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?

Description clearly states it loads relevant memories for session bootstrapping, distinguishes from recall by noting it's optimized for broad context vs specific questions. Verb 'load' plus resource 'memories' is specific.

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 instructs to call at start of every conversation and when switching topics. Contrasts with recall for specific queries, providing 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.

forgetA

Permanently delete a memory by ID. This is a destructive, irreversible operation that soft-deletes the memory record (it will no longer appear in recall or context results). Use forget before storing a corrected version of a fact, to prevent contradictory memories from coexisting. Do not use for bulk cleanup (delete one at a time). Do not use if you are unsure whether the memory is outdated, as deletion cannot be undone. Requires the exact memory ID (UUID), which is returned by recall and context. Costs 1 operation. Returns confirmation on success, or an error if the ID does not exist.

ParametersJSON Schema
NameRequiredDescriptionDefault
memory_idYesUUID of the memory to delete. Get this from recall or context results (the 'id' field). Must be an exact match.

TDQS

A4.9/5.0
Behavior5/5

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

No annotations provided, but the description fully discloses the destructive, irreversible nature of the operation, the soft-delete behavior, the exact ID requirement, operation cost, and return behavior (confirmation or error).

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 thorough and every sentence adds value, but it is relatively long. It could be slightly more compact without losing information, but it remains clear and structured.

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 absence of output schema and annotations, the description covers all critical aspects: purpose, parameters, behavior, usage constraints, and return values. No gaps.

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

Parameters5/5

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

Schema already describes memory_id, but the description adds valuable context: the source of the ID (recall or context results), its format (UUID), and the requirement for exact match.

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 'permanently delete a memory by ID'. It also contrasts with sibling tools like 'context', 'recall', 'remember', and 'share' by being the dedicated deletion tool.

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?

Explicit guidance on when to use ('before storing a corrected version of a fact'), when not to use ('bulk cleanup', 'if unsure'), and implied alternatives (e.g., 'remember' for storing, 'recall' for retrieval).

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

recallA

Search persistent memory by meaning, returning the most relevant past memories ranked by semantic similarity. This is a read-only operation that runs a 4-way hybrid search (vector similarity, BM25 full-text, entity graph traversal, temporal proximity) and reranks results with a cross-encoder model. Use recall (not context) when you need to answer a specific question: "what language does the user prefer?", "how was auth implemented?", "what was decided about the database?". Do not use for broad session bootstrapping (use context instead). Returns up to limit memories with relevance scores (0-1). Costs 1 operation per call. If no memories match, returns an empty list, not an error.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesNatural language search query. Semantic, not keyword-based: 'what programming language does the user prefer?' works better than 'language preference'. More specific queries return more relevant results.
agent_idNoAgent instance identifier. Must match the agent_id used when storing memories. Default: 'default'.default
user_idNoUser identifier. When provided with scope 'user', also searches user-scoped memories shared by other agents.
scopeNoSearch scope. 'agent' (default): only this agent's memories. 'user': also includes memories shared to user scope. 'org': includes org-wide memories. Broader scope returns more results but may include less relevant memories.
tagsNoFilter results to only memories with at least one matching tag. Omit to search all memories regardless of tags.
limitNoMaximum memories to return, 1-20. Default 5. Use higher values (10-20) for broad searches, lower (1-3) for targeted lookups.

TDQS

A4.6/5.0
Behavior5/5

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

Despite no annotations, the description thoroughly discloses behavior: it's a read-only operation, uses a 4-way hybrid search, reranks with cross-encoder, costs 1 operation per call, returns empty list on no match, and returns relevance scores between 0-1. No contradictions with annotations (none provided).

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 well-structured and concise. It starts with purpose, then algorithm, usage guidance, examples, return format, cost, and error handling – all in logical order. Every sentence contributes meaning; no filler. Front-loaded with key information.

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?

Given no output schema, the description explains return format (memories with relevance scores 0-1, up to limit, empty list on no match). It covers behavioral context (cost, algorithm). However, it does not detail the structure of each memory (e.g., fields like text, timestamp). A minor gap, but overall complete for most use cases.

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 100%, so baseline is 3. The description adds little beyond what the schema already provides for parameters. It mentions 'limit' in context of results, but the schema already describes each parameter similarly. No net gain in parameter understanding from the description.

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: 'Search persistent memory by meaning, returning the most relevant past memories ranked by semantic similarity.' It identifies the specific verb (search) and resource (memory), and distinguishes it from siblings (context) by explaining when to use recall vs 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?

The description provides explicit usage guidance: 'Use recall (not context) when you need to answer a specific question... Do not use for broad session bootstrapping (use context instead).' It also gives concrete query examples like 'what language does the user prefer?' and explains when to use higher or lower limit values.

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

rememberA

Store a fact, decision, or preference in persistent memory so it survives across sessions. This is a write operation that creates a new memory record, encrypts the content at rest, and generates a vector embedding for semantic search. Use remember (not recall) when you learn something worth keeping: architecture decisions, user preferences, bug root causes, project conventions, or task outcomes. Do not use for ephemeral scratch data, secrets, or large files. Returns the memory ID and timestamp. Costs 1 operation against the API key's monthly quota (500 free, then paid). Use forget to delete outdated memories before storing corrections, to prevent contradictions.

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYesThe information to store. Write as a complete, self-contained statement (not fragments). Include context: 'User prefers TypeScript for backend services' not just 'TypeScript'. Max 10,000 characters.
agent_idNoUnique identifier for this agent instance. Use a consistent value across sessions so memories are retrievable. Default: 'default'.default
user_idNoUser identifier, required when scope is 'user'. Links the memory to a specific user across all their agents.
tagsNoCategorical labels for filtering during recall. Use lowercase, consistent terms: 'preference', 'decision', 'architecture', 'bug-fix'. Max 20 tags, each max 100 chars.
scopeNoVisibility: 'agent' (only this agent sees it, default), 'user' (all agents for this user, requires user_id), 'org' (all agents in the organization, requires org membership).agent

TDQS

A5/5.0
Behavior5/5

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

Details write operation, encryption at rest, vector embedding generation, return values (ID and timestamp), and API quota cost. No annotations present, so description fully covers behavioral traits.

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?

Six succinct sentences, each adding distinct value. Front-loaded with purpose, followed by usage, behavior, parameters, and cost. No unnecessary 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?

For a write operation with 5 parameters and no output schema, description covers return value, quota, security features, and optimal usage patterns. No gaps identified.

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

Parameters5/5

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

With 100% schema coverage, baseline is 3, but description adds valuable guidance: content format (self-contained with context), tag conventions (lowercase, consistent terms), scope visibility, and agent_id consistency for session persistence.

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 it stores facts/decisions/preferences in persistent memory as a write operation. Distinguishes from recall and forget by name, making purpose unambiguous.

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 advises when to use (learned lasting info) vs not (ephemeral, secrets, large files). Names sibling tools recall and forget as alternatives for reading and deleting.

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

shareA

Widen a memory's visibility scope so other agents can access it. This is a write operation that changes the memory's scope from agent-only to user-level or org-level. Use share when a memory contains knowledge valuable beyond the current agent: user preferences (share to user scope so all agents know), team conventions (share to org scope). Do not use to restrict scope (sharing is one-directional: agent to user to org). Requires the memory ID (from recall or remember) and the target scope. Does not duplicate the memory, only changes its visibility. Costs 1 operation.

ParametersJSON Schema
NameRequiredDescriptionDefault
memory_idYesUUID of the memory to share. Get this from recall, context, or remember results.
target_scopeYesNew visibility level. 'user': all agents serving this user can recall it. 'org': all agents in the organization can recall it. Cannot go back to 'agent' once shared.
user_idNoRequired when target_scope is 'user'. Identifies which user's agents should see this memory.

TDQS

A4.8/5.0
Behavior5/5

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

Despite no annotations, the description fully discloses behavioral traits: it's a write operation that changes scope, does not duplicate memory, is one-directional, and costs 1 operation. It also mentions prerequisites (memory ID from recall/remember) and scope limitations.

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 but dense, with every sentence contributing useful information. It could be slightly better structured with separators for use cases, but it remains clear and front-loaded with purpose.

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 low complexity (3 params, no output schema, no annotations), the description covers all essential aspects: purpose, usage, behavior, parameters, side effects, and constraints. No gaps remain for an agent to understand the tool correctly.

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 coverage is 100%, and the description adds meaning by explaining where memory_id comes from, defining target_scope enum values with usage context, and clarifying when user_id is required. It adds value beyond the schema's property descriptions.

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: 'Widen a memory's visibility scope so other agents can access it.' It specifies the verb (widen/share) and resource (memory), and distinguishes itself from sibling tools like recall and remember by focusing on visibility changes.

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?

The description provides explicit guidance on when to use the tool (e.g., for user preferences share to user scope, for team conventions share to org scope) and when not to use it ('Do not use to restrict scope'). It also explains the directional nature (agent to user to org).

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. 5 tool updatesv0.1.1
    • Changedcontext4 fields changed
      • changedInput schema / properties / agent_id / description
        Previous value: -"Identifier for this agent instance"New value: +"Agent instance identifier. Must match the agent_id used when storing memories. Default: 'default'."
      • changedInput schema / properties / current_context / description
        Previous value: -"A summary of what you're currently working on or discussing. The more specific, the better the recalled memories will be."New value: +"Description of what you are currently working on. Be specific: 'refactoring the authentication middleware in the Express API' retrieves better context than 'working on auth'. This is the search query for memory retrieval."
      • changedInput schema / properties / max_memories / description
        Previous value: -"Maximum number of memories to return"New value: +"Maximum memories to return, 1-20. Default 5. Use 10-15 at session start for broad context loading, 3-5 for topic switches."
      • changedInput schema / properties / user_id / description
        Previous value: -"User identifier to include user-scoped memories"New value: +"User identifier. When provided, also retrieves user-scoped memories shared by other agents."
    • Changedforget1 field changed
      • changedInput schema / properties / memory_id / description
        Previous value: -"The ID of the memory to delete"New value: +"UUID of the memory to delete. Get this from recall or context results (the 'id' field). Must be an exact match."
    • Changedrecall6 fields changed
      • changedInput schema / properties / agent_id / description
        Previous value: -"Identifier for this agent instance"New value: +"Agent instance identifier. Must match the agent_id used when storing memories. Default: 'default'."
      • changedInput schema / properties / limit / description
        Previous value: -"Maximum number of memories to return"New value: +"Maximum memories to return, 1-20. Default 5. Use higher values (10-20) for broad searches, lower (1-3) for targeted lookups."
      • changedInput schema / properties / query / description
        Previous value: -"What to search for. Use natural language — the search is semantic, not keyword-based."New value: +"Natural language search query. Semantic, not keyword-based: 'what programming language does the user prefer?' works better than 'language preference'. More specific queries return more relevant results."
      • changedInput schema / properties / scope / description
        Previous value: -"Search scope: agent (only this agent's memories), user (include user-scoped), org (include org-scoped)"New value: +"Search scope. 'agent' (default): only this agent's memories. 'user': also includes memories shared to user scope. 'org': includes org-wide memories. Broader scope returns more results but may include less relevant memories."
      • changedInput schema / properties / tags / description
        Previous value: -"Filter by tags"New value: +"Filter results to only memories with at least one matching tag. Omit to search all memories regardless of tags."
      • changedInput schema / properties / user_id / description
        Previous value: -"User identifier to include user-scoped memories"New value: +"User identifier. When provided with scope 'user', also searches user-scoped memories shared by other agents."
    • Changedremember5 fields changed
      • changedInput schema / properties / agent_id / description
        Previous value: -"Identifier for this agent instance"New value: +"Unique identifier for this agent instance. Use a consistent value across sessions so memories are retrievable. Default: 'default'."
      • changedInput schema / properties / content / description
        Previous value: -"The information to remember. Be specific and include context so it's useful when recalled later."New value: +"The information to store. Write as a complete, self-contained statement (not fragments). Include context: 'User prefers TypeScript for backend services' not just 'TypeScript'. Max 10,000 characters."
      • changedInput schema / properties / scope / description
        Previous value: -"Visibility scope: agent (only this agent), user (all agents for this user), org (all agents in the organization)"New value: +"Visibility: 'agent' (only this agent sees it, default), 'user' (all agents for this user, requires user_id), 'org' (all agents in the organization, requires org membership)."
      • changedInput schema / properties / tags / description
        Previous value: -"Tags for categorizing the memory (e.g., 'preference', 'decision', 'fact')"New value: +"Categorical labels for filtering during recall. Use lowercase, consistent terms: 'preference', 'decision', 'architecture', 'bug-fix'. Max 20 tags, each max 100 chars."
      • changedInput schema / properties / user_id / description
        Previous value: -"User identifier for user-scoped memories"New value: +"User identifier, required when scope is 'user'. Links the memory to a specific user across all their agents."
    • Changedshare3 fields changed
      • changedInput schema / properties / memory_id / description
        Previous value: -"The ID of the memory to share"New value: +"UUID of the memory to share. Get this from recall, context, or remember results."
      • changedInput schema / properties / target_scope / description
        Previous value: -"Who to share with: user (all agents for this user) or org (all agents in the organization)"New value: +"New visibility level. 'user': all agents serving this user can recall it. 'org': all agents in the organization can recall it. Cannot go back to 'agent' once shared."
      • changedInput schema / properties / user_id / description
        Previous value: -"Required when sharing to user scope"New value: +"Required when target_scope is 'user'. Identifies which user's agents should see this memory."
  2. 5 tool updatesv0.1.0
    • First observedcontext
    • First observedforget
    • First observedrecall
    • First observedremember
    • First observedshare
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0
Disambiguation4/5

While the descriptive text explicitly distinguishes 'context' (broad bootstrap) from 'recall' (specific query), and 'recall' (read) from 'remember' (write), the names 'recall' and 'remember' are near-synonyms in English which could cause initial agent confusion. The boundaries are clear once descriptions are read, but the naming similarity creates slight friction.

Naming Consistency3/5

Four tools use imperative verbs (forget, recall, remember, share) while 'context' uses a noun, breaking the pattern. Additionally, 'recall' and 'remember' are semantically similar (both relate to retrieving memories in common parlance), whereas the server uses them for opposite operations (read vs write). A consistent verb_noun scheme (e.g., load_context, search_memories, create_memory) would be clearer.

Tool Count5/5

Five tools is ideal for this domain: two read modes (broad context vs specific search), one write, one delete, and one permission/scope modifier. Each tool earns its place without redundancy, covering the full memory lifecycle without bloat.

Completeness4/5

Covers CRUD operations well (create via remember, read via context/recall, delete via forget), with update handled intentionally via delete-then-recreate workflow. The 'share' tool adds necessary permission control. Minor gap: no bulk forget operation for cleanup, though descriptions explicitly warn against bulk use.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

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/AlekseiMarchenko/central-intelligence'

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