Skip to main content
Glama
Sign In
fish827-08

kb-memory

by fish827-08
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

read_memory

Fetch the full content of one memory by ID; returns NOT_FOUND when missing. Optionally search a project's store first, then global.

Instructions

按 ID 读取单条记忆完整内容；记录不存在返回 {"error": "NOT_FOUND"}。 project：先查该项目子库，再查全局库；不传时先查全局库再查各项目子库。 client：来源客户端（可选，缺省从 clientInfo 自动识别，仅审计）。 English: Read the full content of a single memory by ID; returns {"error": "NOT_FOUND"} when absent. project: search that project's sub-store first, then the global store; when omitted, global first and then each project store. client is audit-only.

Input Schema

NameRequiredDescriptionDefault
clientNo
projectNo
record_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: the exact NOT_FOUND error shape, the store-resolution order for project lookups (project sub-store then global, vs global then each project store when omitted), and that client is audit-only and auto-detected. It stops short of stating permissions or the success payload shape.

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 core action is front-loaded and each sentence carries information, but the full Chinese/English duplication roughly doubles the length for a single-language agent, which is redundant rather than additive.

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?

No output schema exists, and the description covers the failure return and store-resolution behavior, which are the non-obvious parts. The success payload is only gestured at ('full content'), a minor gap for a read-by-ID tool.

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 description coverage is 0%, so the description must compensate, and it explains two of three parameters well: project's lookup-order semantics and client being optional, auto-detected, and audit-only. record_id is left undefined but is self-evident from 'by ID'.

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 and resource ('Read the full content of a single memory by ID'), and the singular 'by ID' framing cleanly separates it from the sibling search_memory, which returns multiple matches. An agent can pick correctly 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 Guidelines3/5

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

The 'by ID' phrasing implies it is a direct-lookup tool that presupposes a known identifier, but the description never states when to prefer it over search_memory or how to obtain a record_id. Usage is inferred from context rather than stated.

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