Skip to main content
Glama
Sign In
Ragionex Memory MCP

Ragionex Memory MCP

Official
by ragionex
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

View full memory content

ragionex_view_memory
Read-onlyIdempotent

Retrieve full memory records by ID from a selected vault, including content, status, revision, and audit fields. Use revisions to detect conflicts before updating.

Instructions

Read full records by ID within the selected Vault. Requires read permission. Returns id, vault_id, content, created_at, updated_at, status, revision, created_by and updated_by (account IDs). Use the returned revision as expected_revision for an update, and read again after a revision_conflict. A missing or out-of-scope record is not available through this key.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ids": "<ids>"
    },
    "name": "ragionex_view_memory"
  }
}

Input Schema

NameRequiredDescriptionDefault
idsYesRecord IDs from recall or list in the selected Vault.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.7.0
    • changedInput schema / properties / ids / description
      Previous value: -"Memory IDs to fetch. Get IDs from ragionex_list_memories or ragionex_recall_memory."New value: +"Record IDs from recall or list in the selected Vault."
    • addedInput schema / properties / ids / items / pattern
      Added value: +"^[A-Za-z0-9_]{1,14}$"
  2. First observedv0.5.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine context beyond them: a read-permission requirement, the exact returned field set, revision-conflict handling, and that missing/out-of-scope records are simply not available rather than erroring.

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 tight sentences, front-loaded with what the tool does and followed by permission, return shape, and workflow notes. No sentence is filler and nothing repeats structured fields verbatim.

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?

A single-parameter read tool with no output schema, yet the description enumerates the full return payload and conflict/permission behavior. An agent has everything needed to call it and use its result 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 schema already says IDs come from recall or list. The description nonetheless adds behavioral meaning to the parameter: out-of-scope or missing IDs are not returned through this key, so an agent knows absent IDs are silently omitted rather than failing the call.

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?

States a specific verb (read) and resource (full records by ID) bounded to the selected Vault, which cleanly separates it from recall_memory and list_memories that return summaries. The 'full records' framing tells an agent exactly what this tool yields versus its list/recall siblings.

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

Usage Guidelines4/5

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

Gives concrete workflow guidance: use the returned revision as expected_revision for update_memory, and re-read after a revision_conflict. It does not explicitly state when to prefer this over ragionex_recall_memory, but the 'full records by ID' scope makes the division implicit.

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

Deploy Server

Other Tools