What can you do with this server?

The Ratary Memory Server is an AI Brain Platform that provides persistent, structured memory and intelligent retrieval for AI models and agents. It offers the following capabilities: * get_capabilities: Retrieve the deployment's protocol version, tool count, limits, and feature flags — useful for discovering what the deployment supports at session start. * search_memory: Perform hybrid-ranked keyword or semantic searches across persistent memories, returning ranked results with IDs, titles, summaries, and relevance scores. * save_memory: Create a new persistent memory with a title, markdown content, optional project scope, and tags — ideal for preserving decisions, handoffs, or durable facts. * get_memory: Fetch a single memory's full content and metadata by its UUID. * get_context: Assemble token-efficient, ranked context from persistent memories tailored to a specific task or question — typically ~85% fewer tokens than raw memory dumps — suitable for injecting directly into an agent prompt. * list_agent_clients: List certified external agent client profiles registered with the deployment, including their name, transport, and status. Underlying features include hybrid retrieval across SQL, vectors, lexical index, and graph; structured knowledge with metadata and graph traversal; pluggable storage (Postgres, pgvector, R2/S3/MinIO, Neo4j, etc.); and optional enterprise features like RBAC, audit trails, and observability.

Which integrations are available for this server?

Provides Cloudflare D1 as a SQL metadata store option for Ratary Server, enabling serverless database storage. Used as a metadata store for Ratary Server, providing persistent relational storage for memory and knowledge.

Ratary Memory

by ontorata

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

The problem

Why does AI forget between sessions?

Every AI session starts from zero.

Your model forgets yesterday's architecture decisions. Your agent drops customer context between runs. Your coding assistant can't recall why you chose Postgres over DynamoDB. Teams paste the same background into Cursor, Claude, ChatGPT, and custom bots — and knowledge still drifts.

Vector databases store chunks. RAG pipelines retrieve documents. Agent frameworks orchestrate tools.

None of them give AI a durable brain.

Related MCP server: ContextFS

Why Ratary exists

Why build a brain layer now?

AI models are getting cheaper. Context windows are getting larger. Agents are getting capable.

But AI still forgets.

The bottleneck is no longer reasoning. It's memory — durable, structured, retrievable, and owned by you.

Every serious application eventually needed a database. Every serious AI system will need a brain layer: persistent intelligence that sits between your models and your storage — independent of any single vendor, IDE, or agent framework.

AI should remember.
Developers should own that memory.

Ratary exists to be that layer. Applications bring models. Ratary brings the brain.

What Ratary is

What is Ratary?

Ratary is an AI Brain Platform — infrastructure that gives AI:

Persistent memory — durable, owner-scoped, versioned
Structured knowledge — metadata, relations, graph traversal
Intelligent retrieval — hybrid search + bounded context assembly
Protocol access — Ratary MCP, REST, optional gRPC

It sits between AI clients and storage. One brain, many surfaces — Cursor, Claude Code, custom agents, enterprise APIs, and remote MCP hosts.

The runnable deployment is Ratary Server — this repository. Ratary is the product; Ratary Server is what you clone and run.

Bring your model. Ratary brings the memory.

Quick start

How do I run Ratary Server locally?

Ratary is the product. Ratary Server is the open-source deployment you run — ontorata/ratary (this repository). @ratary/sdk, @ratary/cli, and Ratary MCP connect to it; sibling Ontorata products use the same source of truth.

Prerequisites: Node.js 24 · SQL metadata store (pick one — Postgres is the template default)

Path A — PostgreSQL (npm + local or Docker)

git clone https://github.com/ontorata/ratary.git
cd ratary && npm install
cp .env.example .env   # Set AUTH_SECRET + DATABASE_URL — see .env.example QUICK START
npm run db:apply-postgres-schema
npm run setup          # wire Ratary MCP for Cursor, Claude Code, …
npm run dev

Or use Docker: docker compose --profile postgres up --build — see docs/DOCKER.md.

Path B — Cloudflare D1

git clone https://github.com/ontorata/ratary.git
cd ratary && npm install
cp .env.example .env   # Set AUTH_SECRET + SQL_PROVIDER=d1 + CLOUDFLARE_* / D1_*
npm run db:migrate
npm run setup
npm run dev

Details: docs/GUIDE.md · docs/CONFIGURATION.md

→ API http://localhost:9876 · Swagger /docs

First REST call: bootstrap once to get an API key (aic_...) — see GUIDE — First REST API key.

# Save your first memory
curl -X POST http://localhost:9876/api/v1/memory \
  -H "Authorization: Bearer aic_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title":"Hello brain","project":"demo","content":"Ratary remembers this."}'

Full guide: docs/GUIDE.md · SDK & MCP examples in docs/examples/

npm packages (`@ratary`)

Client libraries ship on npm under the @ratary scope — product name, published by Ontorata. No server clone required for SDK, CLI, or hosted MCP.

npm install @ratary/sdk@1.1.0
npx @ratary/mcp-server@1.1.3          # remote REST → stdio MCP
npm install -g @ratary/cli@1.1.0      # operator CLI

Package	Version	Install	Role
`@ratary/sdk`	1.1.0	`npm install @ratary/sdk`	Typed REST client + `client.admin.*`
`@ratary/cli`	1.1.0	`npm install -g @ratary/cli`	Operator commands (`admin`, `connectors`)
`@ratary/mcp-server`	1.1.3	`npx @ratary/mcp-server`	IDE MCP → hosted API

Set RATARY_BASE_URL and RATARY_API_KEY (aic_...). Details: packages/README.md · remote MCP install.

Ecosystem

Which repository owns what?

The Visual architecture diagram shows logical layers inside Ratary Server. This diagram shows repository and product relationships — what ships in this repo, what connects to it, and what lives in sibling Ontorata repositories. Both views describe the same platform from different angles.

Throughout this README, Ratary MCP means the official memory MCP implementation (stdio in this repo · npm @ratary/mcp-server for hosted REST). It is not the same as Ontorata MCP (ecosystem gateway — separate repo).

┌─────────────────────────────────────────────────────────────┐
│                      Ratary Cloud (opt-in)                  │
│         optional hosted deployment · not this repo          │
└──────────────────────────────┬──────────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────────┐
│  Ratary Server          ← ontorata/ratary (this repo)       │
└──────────────────────────────┬──────────────────────────────┘
         │              │              │
         ▼              ▼              ▼
   @ratary/sdk    @ratary/cli   @ratary/mcp-server
   (SDK)          (CLI)         (Ratary MCP · npm)
         │              │              │
         └──────────────┴──────────────┘
                               │
         ┌─────────────────────┴─────────────────────┐
         ▼                     ▼                     ▼
   Ontorata MCP         Ontorata Studio          Ontory Runtime
   ontorata/ontorata-mcp ontorata/Ontorata-Studio  ontorata/ontory-runtime
   ecosystem product     ecosystem product         (ADR-2119; was ontorata/ontory)

Infrastructure (ships from ontorata/ratary — server plus client packages):

Component	Repository	Role
Ratary Server	ontorata/ratary	Memory engine — REST, persistence, Ratary MCP stdio. You run this.
Ratary SDK	npm `@ratary/sdk` · `packages/sdk`	Typed REST client for Ratary Server.
Ratary CLI	npm `@ratary/cli` · `packages/cli`	Operator commands; delegates to Ratary SDK.
Ratary MCP	npm `@ratary/mcp-server` · stdio in repo	Memory MCP — full stdio in clone · npm proxy for hosted REST.

Ecosystem products (separate repositories — connect to Ratary Server; not bundled here):

Product	Repository	Role
Ontorata MCP	ontorata/ontorata-mcp	Ecosystem MCP gateway — Ratary MCP plus additional Ontorata tools.
Ontorata Studio	ontorata/Ontorata-Studio	Operator UI — uses `@ratary/sdk` only.
Ontory	ontorata/ontory-runtime	Ontory Runtime — AI orchestration (ADR-2119). Legacy URL `ontorata/ontory` redirects.

Ratary Server does not depend on ecosystem product repositories.

Ratary MCP vs Ontorata MCP

Which MCP should I install?

	Ratary MCP	Ontorata MCP
Layer	Ratary infrastructure	Ontorata ecosystem product
What it is	Official memory protocol for Ratary Server	Ecosystem gateway for Ontorata products
Scope	Memory — CRUD, search, context, graph	Ratary memory plus additional Ontorata tools
Repository	ontorata/ratary · npm `@ratary/mcp-server`	ontorata/ontorata-mcp
Typical `mcp.json` key	`ratary`	`ontorata`

Use Ratary MCP for direct memory access. Use Ontorata MCP for one MCP entry point across the Ontorata stack. Both use Ratary Server as source of truth.

What Ratary is not

How is Ratary different from alternatives?

	Vector DB	Memory API	RAG	Agent framework	Ratary
Primary job	Similarity search	Key-value recall	Document Q&A	Tool orchestration	Durable AI memory
Structured knowledge & graph	❌	⚠️	❌	⚠️	✅
MCP-native IDE integration	❌	⚠️	❌	⚠️	✅
Token-efficient context assembly	❌	⚠️	❌	⚠️	✅
Self-host & data sovereignty	✅	⚠️	⚠️	⚠️	✅
Clear agent boundary	N/A	⚠️	N/A	❌ bundled	✅ substrate only

Ratary complements your stack — it does not replace pgvector, LangGraph, or your agent of choice. See the Capability matrix for a feature-level comparison.

If you only use…	You get…	What you miss
pgvector	Embedding similarity	Structured memory, graph, MCP, context packing
Mem0	Fast hosted memory API	Full self-host, hybrid retrieval, enterprise adapters
Letta	Agent + memory bundled	Your agent stays yours — Ratary is substrate, not runtime
LangGraph	Workflow & tool routing	Shared durable memory across sessions and clients
RAG	Document chunks	Evolving memory — decisions, handoffs, relations

Visual architecture

How is Ratary Server structured internally?

This diagram shows the logical internal architecture of Ratary — how memory, knowledge, retrieval, and storage layers compose inside the platform. It is not a repository or product map.

        ┌─────────────────────────────────────────┐
        │           Your AI applications           │
        │  Cursor · Claude · Agents · REST · MCP   │
        └────────────────────┬────────────────────┘
                             │
                    MCP · REST · gRPC
                             │
        ┌────────────────────▼────────────────────┐
        │     Ratary Server (logical layers)       │
        │  ┌─────────┐ ┌──────────┐ ┌───────────┐ │
        │  │ Memory  │ │Knowledge │ │ Retrieval │ │
        │  └────┬────┘ └────┬─────┘ └─────┬─────┘ │
        │       └───────────┴─────────────┘       │
        │         Context · Learning · Protocols   │
        └────────────────────┬────────────────────┘
                             │
        ┌────────────────────▼────────────────────┐
        │     Pluggable storage (your choice)      │
        │  Postgres · Supabase · MariaDB · D1 · pgvector · Neo4j · │
        │  R2/S3/MinIO · OpenSearch · ClickHouse · …        │
        └─────────────────────────────────────────┘

Search browses. Retrieval injects context. Embedding enriches asynchronously — never on the CRUD hot path.

Details: docs-ai → products/ratary/roadmap/ARCHITECTURE.md

For repository and product relationships (SDK, CLI, Ratary MCP, Ontorata ecosystem repos), see Ecosystem — a separate diagram, same platform, different perspective.

How Ratary works

What happens to a memory after you save it?

   Write          Enrich         Retrieve        Learn          Reuse
     │               │               │              │              │
     ▼               ▼               ▼              ▼              ▼
  Save via       Summarize,      Rank & pack    Signals,       Same memory
  Ratary MCP/REST embed, link     context for    consolidate,   powers every
                 relations       your prompt    evolve         client

Write — Persist memory through Ratary MCP or REST.
Enrich — Summarize, embed, and relate — asynchronously.
Retrieve — Assemble the smallest useful context slice.
Learn — Optional signals and consolidation improve recall over time.
Reuse — One brain across IDEs, agents, and APIs.

Core capabilities

What can Ratary Server do today?

Memory intelligence

Durable memories with summaries, codenames, favorites, archives, and handoffs. Version history with restore and merge — built for long-running work, not chat logs.

Knowledge

Semantic enrichment, relation linking, and graph traversal. Memory becomes navigable knowledge — not a flat pile of notes.

Retrieval

Hybrid search across SQL, vectors, lexical index, and graph. Separate browse from inject. Optional precision modes (hybrid, semantic, fulltext, title) when you need more control.

Reasoning support

Progressive retrieval, token budgets, and summary-first context assembly — typically ~85% fewer tokens than dumping full memory bodies into prompts.

Learning

Quality signals, consolidation, and compression — optional pipelines that improve the brain over time without retraining your model.

External agent support

Capability manifests, workspace scoping, and 28 Ratary MCP tools. External agents discover what the brain can do; Ratary never embeds agent reasoning — see What Ratary is not.

Platform

Pluggable adapters: choose SQL metadata (Postgres, Supabase, MariaDB/MySQL, D1, TiDB/Cockroach) plus optional pgvector, R2/S3/MinIO, Azure Blob, GCS, Meilisearch, OpenSearch, Neo4j, Redis, DuckDB, ClickHouse. Same application code for every backend.

Self-host stacks: docs/DOCKER.md — postgres or enterprise (MariaDB + MinIO + Redis) profiles.

Cloud & enterprise

Self-host, deploy to Vercel, or run a control plane with metering and federation. RBAC workspaces, audit trails, SSO, and policy hooks — opt-in when you need them.

Observability

OpenTelemetry, Prometheus metrics, SLO dashboards, and cost visibility for production brains.

Developer experience

OpenAPI, npm @ratary/sdk@1.1.0 · @ratary/cli@1.1.0 · @ratary/mcp-server@1.1.3 — and one-command IDE setup (npm run setup).

Knowledge fabric (opt-in)

Ingest from external systems of record — Notion (live on hosted prod), Confluence, Google Drive, SharePoint, and Teams connectors (code complete · enable per connector via env). Webhook HMAC, incremental sync, provenance on memories. Flags: KNOWLEDGE_FABRIC_ENABLED + CONNECTOR_SYNC_ENABLED. Guides: Knowledge fabric · Production enable · Phases 32–34 in docs-ai.

Use cases

Who is Ratary for?

	What you build	What Ratary provides
Developer AI	Coding assistants across IDEs and sessions	Persistent project memory, MCP tools, handoffs
Enterprise search	Internal knowledge discovery	Hybrid retrieval over structured memory, not just files
Customer support	AI that handles tickets	Durable customer context without re-prompting every thread
Knowledge management	Team second brain	Graph-linked memories, codenames, relations, summaries
Autonomous agents	Multi-agent systems	Shared memory layer with workspace and agent scoping
Personal AI	Private assistant you own	Self-hosted, exportable, sovereign data

Capability matrix

How does Ratary compare feature-by-feature?

For category positioning, see What Ratary is not.

Capability	Ratary	Vector DB	Memory API	RAG	Agent framework
Persistent structured memory	✅	❌	⚠️	❌	⚠️
MCP-native	✅	❌	⚠️	❌	⚠️
Hybrid SQL + vector + graph	✅	⚠️	⚠️	⚠️	⚠️
Token-efficient context assembly	✅	❌	⚠️	❌	⚠️
Knowledge graph & relations	✅	❌	⚠️	❌	⚠️
Self-host sovereignty	✅	✅	⚠️	⚠️	⚠️
Agent boundary (bring your agent)	✅	N/A	⚠️	N/A	❌
Enterprise storage adapters	✅	✅	⚠️	⚠️	⚠️

Documentation

Where do I read next?

Engineering knowledge (internal)

Architecture, ADRs, roadmap, phases, design history, and reviews live in the Ontorata Knowledge OS:

https://github.com/ontorata/docs-ai → products/ratary/

Operator / developer guides (this repository)

Ratary Server (ontorata/ratary — this repository):


docs/GUIDE.md	Setup, daily usage, Ratary MCP configuration
docs/install/README.md	Per-harness MCP / plugin installation
docs/DOCKER.md	Container & Compose self-host
docs/CONFIGURATION.md	Environment variables — what each flag does
docs/examples/	MCP and IDE config templates
MCP/README.md	Ratary MCP — stdio and `@ratary/mcp-server`
packages/README.md	npm packages — install, env, publish
.env.example	Env template — meanings in docs/CONFIGURATION.md
docs/PRODUCTION-ENABLE.md	Hosted deploy — knowledge fabric on Vercel
docs/OPS-PRODUCTION-VERIFY.md	Production ops checklist — `npm run ops:verify-production`
docs/MCP-CHATGPT-OAUTH.md	ChatGPT MCP OAuth + Keycloak IdP runbook
MCP/submission/directory-status.md	MCP directory listing status
docs/ENTERPRISE-MODULES.md	Enterprise flags (opt-in)
CHANGELOG.md	Release notes and version map
SECURITY.md	Vulnerability reporting
ontorata/docs-ai	Architecture · ADR · phases · evidence (Knowledge OS)

Canonical hosted API: https://ratary.ontorata.com (self-host uses your own base URL).

Ontorata ecosystem (separate repositories — not in this tree):


ontorata/ontorata-mcp	Ontorata MCP — ecosystem gateway
ontorata/Ontorata-Studio	Ontorata Studio — operator UI (setup)

Roadmap

What is shipping when?

Canonical roadmap / phase history: ontorata/docs-ai → products/ratary/roadmap/ · products/ratary/phases/

Organized by direction — not sprints. Phases 1–31 are implemented in code (gates PASS); platform modules stay opt-in via env unless noted.

	Themes	Code	Ops (prod)	Primary repository
Today (v1.0)	Ratary MCP + REST, hybrid/graph retrieval, peer SQL, Docker, npm `@ratary/sdk@1.1.0` · `@ratary/mcp-server@1.1.3`, remote MCP, Ontorata Studio. Platform (opt-in): knowledge fabric (Notion/Confluence/Drive/SharePoint/Teams live), universal memory fabric (Phase 32), Neptune traversal (Phase 33), federation, global intelligence	✅	Partial	`ontorata/ratary`
Ops (now)	Prod connector creds · MCP directory follow-ups · ChatGPT OAuth IdP (Keycloak)	✅	⏳	`ontorata/ratary`

Ops status (2026-07-19): Notion + fabric/federation flags on Vercel ✅ · D1 db:migrate ✅ · SDK codegen CI ✅ (workflow) · Confluence/Drive/SharePoint/Teams creds ⏳ (owner secrets) · Keycloak IdP ⏳ (auth.ontorata.com → deploy Render; prod uses Smithery API-key mode until OAuth enabled) · MCP listings mostly Listed (directory-status.md). Verify: npm run ops:verify-production · OPS-PRODUCTION-VERIFY.md

Enterprise modules ship opt-in via environment flags on Ratary Server — defaults stay lean. See ENTERPRISE-MODULES.md and CONFIGURATION.md.

Vision

What is Ratary building toward?

Today every application has a database.

Tomorrow every AI will have a brain.

Ratary is building that layer — open, portable, self-hostable, and protocol-native. Not another chat wrapper. Not another vector dump. Infrastructure for persistent intelligence.

Knowledge should accumulate. Boundaries should be respected. Agents should stay coherent across time.

If you're building AI that lasts longer than a single prompt — build on Ratary.

Contributing

How do I contribute?

Ratary Server (this repo): fork ontorata/ratary → branch → npm run lint && npm run build && npm test → PR to ontorata/ratary.

Standard PR gate:

npm run lint && npm run build && npm test

Org-memory / recall changes (maintainers with .ai/ workspace): run the full gate before merge — see docs/RATARY-VALIDATION-RUNBOOK.md:

npm run ci:ratary-validation

Production ops changes (Vercel env, connectors, OAuth): see docs/OPS-PRODUCTION-VERIFY.md:

npm run ops:verify-production

Extended governance (.ai/ phases, ADRs) lives in the development mirror — optional for contributors; docs-only and standard PRs to ontorata/ratary are welcome without the mirror.

Ontorata MCP and Ontorata Studio accept contributions in their own repositories — not via this repo.

Questions: hello@ontorata.com

Available Tools

6 tools

get_capabilitiesA

Read-onlyIdempotent

Return the Ratary deployment capability manifest (protocol version, tool count, limits, feature flags). Read-only and idempotent; requires RATARY_API_KEY. Use at session start to discover what this deployment supports. Do not use for recalling memories — use search_memory or get_context instead. Returns a JSON capability object (no side effects).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it requires RATARY_API_KEY, returns JSON, and has no side effects, which adds value beyond annotations.

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 short sentences, no redundancy, perfectly front-loaded with the core 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?

No output schema, but description explicitly states it returns a JSON capability object. For a zero-parameter, read-only tool, this fully informs the agent.

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?

No parameters exist, so schema coverage is 100%. Baseline for zero parameters is 4; description correctly omits param details.

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 returns a 'Rassay deployment capability manifest' with specific fields like protocol version, tool count, etc. Distinguishes from sibling tools by explicitly stating not to use for memory recall.

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 to use at session start to discover deployment support. Provides clear alternatives for memory tasks: 'use search_memory or get_context instead'.

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

get_contextA

Read-onlyIdempotent

Assemble token-efficient ranked context for a coding task from persistent memories (summaries by default). Read-only; does not write memories. Requires RATARY_API_KEY. Use at the start of implementation or when answering with organizational memory. Prefer search_memory when you need raw ranked hits to inspect individually. Prefer get_memory for a known UUID. Returns markdown/JSON context suitable for injecting into the agent prompt.

ParametersJSON Schema

Name	Required	Description	Default
`task`	Yes	Natural-language task or question used as the retrieval query (e.g. "fix Glama TDQS scores for mcp-server tools").
`project`	No	Optional project slug to scope retrieval (e.g. "ratary").

TDQS

A4.7/5.0

Behavior5/5

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

Discloses read-only nature (matching readOnlyHint=true), requires RATARY_API_KEY, and states it does not write memories (consistent with destructiveHint=false). No contradictions with annotations.

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?

Five sentences, each with distinct value: action, read-only, API key, usage guidelines, alternatives. Front-loaded with main purpose. No fluff.

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 no output schema, description covers return format ('markdown/JSON context'), auth requirement, and ties to sibling tools. Adequate for agent decision-making.

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 100% with good parameter descriptions. The description adds no significant extra meaning beyond the schema, meeting baseline but not exceeding.

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 it assembles token-efficient ranked context from persistent memories for a coding task, explicitly read-only. It distinguishes itself from siblings like search_memory and get_memory by name and purpose.

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?

Provides explicit when to use ('at start of implementation or when answering with organizational memory') and when to prefer alternatives ('Prefer search_memory... Prefer get_memory...').

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

get_memoryA

Read-onlyIdempotent

Fetch one memory by UUID, including full content and metadata. Read-only and idempotent; requires RATARY_API_KEY. Use when you already know the memory id (from search_memory or a prior save_memory). Do not use for keyword discovery — use search_memory. Do not use to assemble multi-memory task context — use get_context. Returns the memory JSON or an API error if the id is missing.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Memory UUID returned by save_memory or search_memory.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds 'requires RATARY_API_KEY' and mentions error behavior for missing id, which goes beyond annotations.

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 efficient sentences with no redundancy. Front-loaded: purpose first, then behavior, then usage guidance, then error handling.

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 simple 1-parameter tool with strong annotations, the description covers purpose, context, behavior, and error cases fully.

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 100% with parameter description already clear. Description repeats the UUID source but adds no new semantic detail beyond the schema.

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 fetches one memory by UUID with full content and metadata. It distinguishes itself from siblings like search_memory and get_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?

Explicit when-to-use: 'when you already know the memory id'. Explicit when-not-to-use: 'Do not use for keyword discovery' and 'Do not use to assemble multi-memory task context' with alternatives named.

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

list_agent_clientsA

Read-onlyIdempotent

List certified external agent client profiles registered with this Ratary deployment (name, transport, status). Read-only and idempotent; requires RATARY_API_KEY. Use for ecosystem/discovery questions about which clients are supported. Do not use for memory CRUD or retrieval — use save_memory / search_memory / get_context. Returns a JSON list of client profiles (no side effects).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already indicate readOnlyHint, idempotentHint, destructiveHint=false. Description adds auth requirement (requires RATARY_API_KEY) and return format (JSON list, no side effects), going beyond annotations.

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 concise sentences with no wasted words. Front-loaded: first sentence states purpose, then attributes, usage guidance, and return info.

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 parameterless list tool with comprehensive annotations and no output schema, description covers auth, idempotency, return format, and usage guidance completely.

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?

No parameters, schema coverage is 100%, and baseline for 0 parameters is 4. Description implicitly confirms it is parameterless; no additional info needed.

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 lists certified external agent client profiles, including specific fields (name, transport, status). Distinguishes from sibling tools by explicitly stating not for memory CRUD or retrieval.

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 for ecosystem/discovery questions about supported clients and provides clear alternatives (save_memory, search_memory, get_context) for other use cases.

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

save_memoryA

Create a new persistent coding memory (title + markdown body) scoped to an optional project and tags. Side effect: writes a new record via the Ratary REST API; not idempotent (each call creates another memory). Requires RATARY_API_KEY. Does not overwrite existing memories — use get_memory/search_memory first if updating. Use after decisions, handoffs, or durable facts the agent should recall later. Do not use for ephemeral chat notes that should not persist. Returns the created memory JSON including id/codename/timestamps.

ParametersJSON Schema

Name	Required	Description
`tags`	No	Filter tags (e.g. ["handoff", "phase-4"]). Optional.
`title`	Yes	Short human-readable title (e.g. "P1-A Task 7 acceptance gate").
`content`	Yes	Full markdown body stored as the memory content.
`project`	No	Project slug for scoping (e.g. "ratary", "ontorata"). Optional.

TDQS

A4.7/5.0

Behavior5/5

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

The description discloses side effects (writes via REST API), non-idempotency (each call creates another memory), and that it does not overwrite. This adds value beyond annotations (readOnlyHint=false, destructiveHint=false).

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 at four sentences, front-loaded with purpose, then side effect, then usage guidelines. Every sentence adds necessary information without waste.

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 4 parameters (2 required), no output schema, and good annotations, the description covers purpose, side effect, idempotency, prerequisites (RATARY_API_KEY), and usage guidelines. It is complete for the agent's needs.

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 100% and parameters are well-described in the schema. The description adds no extra meaning beyond the schema, such as format or constraints, so baseline score of 3 is appropriate.

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 creates a new persistent coding memory, specifying the resource (memory with title + markdown body) and optional scoping. It distinguishes itself from sibling tools like get_memory and search_memory by focusing on creation.

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 explicitly states when to use ('after decisions, handoffs, or durable facts') and when not to use ('not for ephemeral chat notes'). It also advises to use get_memory/search_memory first if updating, providing clear context.

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

search_memoryA

Read-onlyIdempotent

Search persistent coding memories with hybrid ranking and return ranked hits (id, title, summary, relevance). Read-only; does not create or modify memories. Requires RATARY_API_KEY. Use when you need candidate memories matching a keyword/question before answering. Prefer get_memory when you already have a memory UUID. Prefer get_context when you need token-bounded context assembled for a task (not a raw hit list). Returns JSON search results; empty list means no matches.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max hits to return (default server-side; typical 10–50). Optional.
`query`	Yes	Full-text / hybrid search string (e.g. "phase-4 handoff", "AUTH-0001 postgres decision"). Required.

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it is read-only, does not create/modify, requires RATARY_API_KEY, and returns JSON with empty list for no matches. 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.

Conciseness5/5

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

Four sentences, front-loaded with purpose, then usage guidance and sibling differentiation. No wasted 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?

Covers all aspects: purpose, usage, parameters, siblings, return format, and auth requirement. No output schema needed as description explains return.

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 schema already describes parameters. Description adds value by providing example queries and notes on limit being optional with server default (typical 10-50). Not perfect—could mention if limit is actually optional or default.

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?

Clear verb 'search persistent coding memories', specifies return fields (id, title, summary, relevance), and distinguishes from siblings like get_memory and get_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 states when to use (when need candidate memories before answering) and when not (prefer get_memory or get_context). Also notes requirement for RATARY_API_KEY.

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.

6 tool updatesv0.1.1Jul 13, 2026
- Changedget_capabilities1 field changed
  - addedInput schema / additionalProperties
```
false
```
- Changedget_context3 fields changed
  - addedInput schema / additionalProperties
```
false
```
  - addedInput schema / properties / project / description
```
"Optional project slug to scope retrieval (e.g. \"ratary\")."
```
  - addedInput schema / properties / task / description
```
"Natural-language task or question used as the retrieval query (e.g. \"fix Glama TDQS scores for mcp-server tools\")."
```
- Changedget_memory2 fields changed
  - addedInput schema / additionalProperties
```
false
```
  - addedInput schema / properties / id / description
```
"Memory UUID returned by save_memory or search_memory."
```
- Changedlist_agent_clients1 field changed
  - addedInput schema / additionalProperties
```
false
```
- Changedsave_memory5 fields changed
  - addedInput schema / additionalProperties
```
false
```
  - addedInput schema / properties / content / description
```
"Full markdown body stored as the memory content."
```
  - addedInput schema / properties / project / description
```
"Project slug for scoping (e.g. \"ratary\", \"ontorata\"). Optional."
```
  - addedInput schema / properties / tags / description
```
"Filter tags (e.g. [\"handoff\", \"phase-4\"]). Optional."
```
  - addedInput schema / properties / title / description
```
"Short human-readable title (e.g. \"P1-A Task 7 acceptance gate\")."
```
- Changedsearch_memory5 fields changed
  - addedInput schema / additionalProperties
```
false
```
  - addedInput schema / properties / limit / description
```
"Max hits to return (default server-side; typical 10–50). Optional."
```
  - addedInput schema / properties / limit / maximum
```
100
```
  - addedInput schema / properties / limit / minimum
```
1
```
  - addedInput schema / properties / query / description
```
"Full-text / hybrid search string (e.g. \"phase-4 handoff\", \"AUTH-0001 postgres decision\"). Required."
```
6 tool updatesv0.1.0Jul 13, 2026
- First observedget_capabilities
- First observedget_context
- First observedget_memory
- First observedlist_agent_clients
- First observedsave_memory
- First observedsearch_memory

Install Server

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

TDQS

A4.6/5.0

Disambiguation5/5

Each tool serves a distinct purpose: capabilities discovery, context assembly, single memory fetch, client listing, memory creation, and memory search. No two tools overlap in functionality, and descriptions clearly differentiate them.

Naming Consistency5/5

All tool names follow the consistent verb_noun pattern with underscores: get_capabilities, get_context, get_memory, list_agent_clients, save_memory, search_memory. No mixing of conventions.

Tool Count5/5

With 6 tools, the set is well-scoped for a memory management server. Each tool addresses a fundamental operation, and the count is neither too sparse nor excessive for the domain.

Completeness3/5

The tools cover creation (save_memory) and read operations (get_memory, search_memory, get_context), but lack update and delete tools. This leaves a notable gap in memory lifecycle management, though the core retrieval and storage are handled.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

CrowTerminal - External Brain for AI Agents
io.github.WillNigri
External Brain for AI Agents - persistent versioned memory for creators
Knowledge & Memory Autonomous Agents RAG Systems
2
recordari A
io.recordar.api
Persistent knowledge graph for AI-augmented teams. Store decisions, findings, and standing rules across agent sessions with semantic search and typed connections. Includes cross-session memory, audit trail, workspace isolation, and secret detection. Built for teams running agents that need to remember. Free until launch with team tier as default, anon trial available.
Databases Knowledge & Memory Security
162
Agently Brain
dev.agently
Company brain for AI agents — temporal knowledge graph search, exploration, and durable memory.
Knowledge & Memory Search RAG Systems
1
Ace Memory B
io.github.rudedoggg
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Knowledge & Memory RAG Systems Autonomous Agents
4

Related MCP Servers

Knowledge Graph Memory Server
Knowledge & Memory Databases
modelcontextprotocol
A
license
B
quality
A
maintenance
A basic implementation of persistent memory using a local knowledge graph. This lets Claude remember information about the user across chats.
Updated 3 days ago (2026-09-03 01:42 UTC)
9
73,646
90,042
-
ContextFS
Knowledge & Memory RAG Systems Developer Tools
contextfs
A
license
Not graded
quality
C
maintenance
Universal AI memory layer that provides cross-client, cross-repo context management with semantic search, automatic code indexing, and session management. Enables persistent developer memory across projects with typed memories, graph-based relationships, and RAG-powered retrieval.
Updated 6 months ago (2026-03-09 02:25 UTC)
4
MIT
Remembra
Knowledge & Memory RAG Systems AI & Machine Learning
remembra-ai
A
license
Not graded
quality
A
maintenance
Persistent memory layer for AI agents with entity resolution, PII detection, AES-256-GCM encryption at rest, and hybrid search. Self-hosted. 100% on LoCoMo benchmark.
Updated 2 months ago (2026-07-17 04:31 UTC)
15
MIT
Sovereign Universal Memory MCP
Knowledge & Memory RAG Systems Autonomous Agents
nnaveenraju
A
license
Not graded
quality
D
maintenance
Provides a persistent, vendor-neutral memory layer that allows AI tools and agents to share context and knowledge across different platforms while maintaining local data ownership. It enables users to store, recall, and manage structured memories through hybrid semantic search and automated context assembly.
Updated 6 months ago (2026-03-20 05:54 UTC)
16
Apache 2.0

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/ontorata/ratary'

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

The problem

Why Ratary exists

What Ratary is

Quick start

Path A — PostgreSQL (npm + local or Docker)

Path B — Cloudflare D1

npm packages (@ratary)

Ecosystem

Ratary MCP vs Ontorata MCP

What Ratary is not

Visual architecture

How Ratary works

Core capabilities

Memory intelligence

Knowledge

Retrieval

Reasoning support

Learning

External agent support

Platform

Cloud & enterprise

Observability

Developer experience

Knowledge fabric (opt-in)

Use cases

Capability matrix

Documentation

Engineering knowledge (internal)

Operator / developer guides (this repository)

Roadmap

Vision

Contributing

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

npm packages (`@ratary`)