mh_get
Retrieve the complete content of a specific memory by providing its unique ID.
Instructions
按 id 取单条记忆完整内容。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Retrieve the complete content of a specific memory by providing its unique ID.
按 id 取单条记忆完整内容。
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. '取' and '完整内容' make clear this is a read operation returning the full memory, but it does not mention behavior for missing ids, output format, permissions, or potential side effects. For a simple get operation this is acceptable but not rich.
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?
The entire description is one short, front-loaded sentence with no filler. It conveys the key action, object, and selection criterion efficiently.
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 single-id fetch operation, the description covers the essential action. However, with no output schema and no annotations, it leaves open the exact return structure and edge-case behavior (e.g., non-existent id). The description is minimally viable but not fully self-sufficient for an agent operating without additional context.
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?
The schema documents 'id' as a required UUID but provides no description (0% coverage). The description adds that the id selects a single memory, which is useful, but beyond that it does not elaborate on the parameter's meaning or constraints. The parameter is simple enough that the schema plus minimal reference is adequate.
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 description uses a clear verb ('取' / get) and a specific resource ('单条记忆完整内容' / full content of a single memory), and explicitly ties retrieval to an id. This distinguishes it from sibling tools like mh_search (query-based) and mh_write/mh_update (mutating operations).
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 description implies when to use the tool: when you have a known id and need the complete memory record rather than search results. However, it does not explicitly contrast with mh_search or state when not to use it, leaving the routing partially implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.