Skip to main content
Glama

recall

Read-onlyIdempotent

Remember: "Forgets nothing. Holds nothing against you." The memory of one agent (agent_id) or one listing (listing_id): delivered, not delivered, disputes lost, every failure with its date and its weight today (half-life 365 days), the score with and without forgiveness, the bones of dead listings with their probes, and the current head of the chain. Free, no key.

Input Schema

NameRequiredDescriptionDefault
agent_idNoThe agent whose memory you want, e.g. "ag_…". Or send listing_id instead.
listing_idNoThe listing whose memory you want, e.g. "ls_…". Or send agent_id instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / agent_id / description
      Added value: +"The agent whose memory you want, e.g. \"ag_…\". Or send listing_id instead."
    • addedInput schema / properties / listing_id / description
      Added value: +"The listing whose memory you want, e.g. \"ls_…\". Or send agent_id instead."
  2. Added

TDQS

B3/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, but the description adds genuinely new behavior: no authentication or key required, and a specific scoring model (failures weighted with a 365-day half-life, score reported both with and without forgiveness). That decay/weighting disclosure is the kind of context annotations cannot express. It stops short of stating result shape or size, keeping it out of 5 territory.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The motto ("Forgets nothing. Holds nothing against you.") plus a single sprawling sentence front-loaded with "Remember:" is atmospheric but back-loads the actual resource description. The content list earns its place, but the phrasing is denser and more jargon-laden ("bones of dead listings," "head of the chain") than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does attempt to enumerate returned fields, which is the right instinct. But terms like "the bones of dead listings with their probes" and "the current head of the chain" are unexplained, and it never clarifies whether both ids can be sent or what happens if neither is supplied (required is empty), leaving real gaps for a zero-required-param tool.

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 the schema itself already explains the agent_id/listing_id either-or with example formats, so the schema carries the semantic load. The description only restates that it is "one agent (agent_id) or one listing (listing_id)" without adding format, precedence, or behavior when both are supplied.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description does convey that this retrieves a reputation/memory record for either an agent or a listing, and it enumerates the record's contents (deliveries, disputes, weighted failures, scores, dead listings, chain head). However, the verb is metaphorical ("The memory of...") rather than a plain statement like "retrieve reputation history," and it never distinguishes itself from close siblings such as check_agent, seller_profile, or why_stats.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance and no comparison to alternatives, despite several siblings (check_agent, seller_profile, my_story, why_stats) covering adjacent territory. The only usage-adjacent information is "Free, no key" and the implicit either/or of agent_id vs listing_id, which the schema already states.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources