get_memory

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

No annotations are provided, so the description itself must convey behavior. It explains the mechanism well: the content is returned verbatim from the maintenance file, with no re-summarizing, rewriting, or splitting. It also warns that historical text is material and not instructions, which is valuable protection against prompt injection. Minor gaps remain: nothing is said about invalid IDs, permissions, or what happens when the content is very large.

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

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

Four short lines, leading with what the tool returns and then the key constraint, the integrity behavior, and the safety note. No sentence is filler; each adds a distinct fact.

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

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

For a simple single-parameter fetch tool, the essentials are covered: purpose, prerequisite sourcing of the ID, fidelity of the returned content, and a safety caveat. With no annotations and an output schema that already describes the return shape, little else is strictly needed; details such as behavior for a not-found ID or very long content are the only omissions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% for the single parameter; the schema gives only 'Memory Id'. The description compensates by defining the parameter's provenance, which is that it must come from search_memory, so the agent knows it is an opaque ID rather than a title or free-text query. That is real added meaning beyond the schema.

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

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

The definition gives a clear verb-and-resource pair: 读取 (read) a 历史剧情阶段的完整人工整理内容 (complete manually-curated content of one historical plot stage). The required memory_id and the word 完整 make it clear that this is a single-record fetch rather than a search or list. It does not explicitly contrast itself with the sibling get_memories, but the statement that the ID must come from search_memory already implies that this tool is the step after search.

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

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

The definition states a clear prerequisite, 'memory_id 必须来自 search_memory', which tells the agent to call search_memory first and use this tool only to fetch a specific result. It does not say when not to use it, nor does it mention get_memories or list_memory_tags as alternatives, so the guidance is clear but not complete.

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