Ratary Memory
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RATARY_API_KEY | Yes | API key (aic_...) | |
| RATARY_BASE_URL | Yes | Ratary Server base URL (e.g. https://ratary.ontorata.com) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_capabilitiesA | 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). |
| search_memoryA | 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. |
| 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. |
| get_memoryA | 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. |
| get_contextA | 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. |
| list_agent_clientsA | 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). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
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.
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.
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.
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.