memory_statsTrack long-term memory counts, types, and namespace distribution in Memory Bridge to audit stored knowledge and verify isolation boundaries.
查看长期记忆数量、类型和命名空间分布。
| Name | Required | Description | Default |
|---|---|---|---|
| _memoryRequestKey | No | 兼容代理注入的内部请求键，用于合并同一次模型工具调用 |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds value by naming the returned dimensions (count, types, namespace distribution), which is useful given no output schema, but says nothing about refresh cost, scoping, or freshness of the statistics.
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?
A single short sentence with no waste, front-loading the action and stating exactly what is reported. Nothing could be removed without losing information.
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 read-only, zero-required-parameter stats tool whose annotations already cover the safety profile, the definition is essentially complete: it names the metrics returned and the internal parameter is documented in the schema. The absence of an output schema is partly compensated by the enumeration of returned dimensions.
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 description coverage is 100% for the single parameter (_memoryRequestKey), which is an internal proxy-injected key already documented in the schema. The description adds no parameter-level detail, so the baseline of 3 applies when the schema carries the full load.
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?
States a specific verb (查看/view) and resource (长期记忆/long-term memory) and even enumerates what is surfaced: count, types, and namespace distribution. This clearly separates it from retrieval siblings like memory_list or memory_recall, though it never names an alternative explicitly.
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 purpose implies the usage context (inspecting aggregate state of the memory store rather than reading or mutating entries), so an agent can infer when to reach for it, but there is no explicit when-to-use guidance, no exclusions, and no mention of any sibling as an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.