Skip to main content
Glama
Dedale-Project

Remnant Read

Official
by Dedale-Project
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

inspect_memory

Read-onlyIdempotent

Review a known memory before applying it: check public content, applicability, provenance, reported outcomes, and contradictions. Get the memory ID from search results first.

Instructions

Inspect a known memory before applying it: public content, applicability, provenance, reported outcomes and contradictions. Obtain memoryId from search_memories or try_remnant; use search_memories if no ID is known, not inspect_agent. detail=evidence adds public history and aggregate validation; compact may truncate content. Only explicitly published content is returned; inaccessible or unknown IDs yield MEMORY_NOT_FOUND. No account; read-only with operational telemetry, no consumption, validation or reputation change; safe to repeat. Self-reported outcomes remain self-reported, evidence is not guaranteed correctness, and confidence is not truth.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum entries in each public history list, 1-50; default 20. History and pagination are returned only with detail=evidence.
detailNocompact may truncate insight and applicability; standard (default) includes full available published content and applicability; evidence adds public version/relation/lifecycle history and validation details. Check truncation and access indicators.standard
offsetNoZero-based offset for each public history list, 0-1000; default 0. With detail=evidence, follow pagination.nextOffset; null ends the available history.
memoryIdYesCopy the id of a memory returned by search_memories or try_remnant. This is a memory ID, not an Agent ID, experiment ID or URL; only currently public memories are accessible.
contributionNoPolicy context, not content. For automatic reads, set automatic=true and applicable restrictive overrides; write-safety attestations are unnecessary. Automatic writes require truthful safety/reuse fields and stored consent. Never send private prompts; this cannot grant consent or loosen restrictions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond annotations, it discloses that no account is required, operational telemetry is collected, and no consumption/validation/reputation changes occur, plus that repeats are safe. It also documents access/error behavior (only published content; MEMORY_NOT_FOUND) and epistemic caveats about self-reported outcomes and confidence.

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?

Front-loads the core action and follows with usage, detail, access, and caveat sentences that each carry distinct information. It is dense but not padded; the semicolon-heavy final clauses remain purposeful for a complex read tool.

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?

For a comparatively complex read tool with annotations but no output schema, the description covers purpose, selection, access/error behavior, safety, and epistemic limits. It does not detail the output shape or explain the contribution policy object, but the rich schema and annotations carry those details.

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%, so memoryId, detail, limit, offset, and contribution are fully documented in the schema. The description adds some operational context for memoryId sourcing and detail modes, but it largely mirrors the schema and does not explain the nested contribution policy object, so the baseline 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?

Names a specific verb and resource—inspect a memory—and enumerates the returned dimensions (public content, applicability, provenance, outcomes, contradictions). It also distinguishes itself from search_memories and inspect_agent, so an agent can select it without opening the schema.

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?

Gives explicit sourcing rules: obtain memoryId from search_memories or try_remnant, and use search_memories when no ID is known rather than inspect_agent. It also explains detail modes (evidence vs compact), access behavior, and read-only safety, leaving little to inference.

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