Engram

Overview Schema Source Related Servers Discussions Admin

get_recall

Read-onlyIdempotent

Retrieves a structured memory bundle for starting new tasks or cross-tool handoffs, combining identity, recent activity, relevant knowledge, and governance metadata.

Instructions

获取结构化 Recall Surface v1 载荷。 / Get a structured Recall Surface v1 payload.

用途：在新任务、跨工具接续或需要"一次拿到可执行记忆包"时调用。
返回身份摘要、最近活动、项目/查询相关知识和治理元数据。
Purpose: Call when a new task or cross-tool handoff needs one structured,
actionable memory bundle: identity slice, recent activity, relevant
knowledge, and governance metadata.

只返回已审核且当前有效的知识；预算裁掉内容时 meta.omitted 给出 {omitted_count, ids, sections, reason}。
Returns reviewed, current knowledge only; when the budget drops items,
meta.omitted reports {omitted_count, ids, sections, reason} (no content).

注意：该聚合视图可能组合多类知识和最近上下文，因此治理开启时仅 owner
(private-self) 可读；非 owner 会在读取前被拒绝，不触发搜索或遥测写入。
Note: Because this aggregate view can combine multiple knowledge classes and
recent context, it is owner-only when governance is enabled. Non-owners are
refused before any search or telemetry side effect runs.

Args:
    project_folder: 项目文件夹路径（可选）。 / Project folder path (optional).
    query: 可选搜索焦点。 / Optional search focus.
    limit: 最多返回多少条知识（默认 8，上限 20）。 / Max knowledge items (default 8, max 20).
    token_budget: 知识片段的粗略 token 预算（默认 2000）。 / Rough token budget for knowledge items.
    include_freshness: 是否附加 freshness 提示。 / Attach freshness hints.
    collapse_versions: 保留兼容；被取代的旧版本、待审和已归档条目一律不进入召回。 / Kept for compatibility; superseded versions, pending and archived items never enter recall.
    include_playbooks: 是否附带 playbook 指针桶（v4.20，默认 False；元数据+240 字描述预览，完整步骤永不入召回，最多 2 条且 ≤25% 知识预算）。 / Attach the playbook pointer bucket (v4.20, default False; metadata + 240-char description preview, full steps never enter recall, max 2 items and <=25% of the knowledge budget).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_recall"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`query`	No
`token_budget`	No
`project_folder`	No
`collapse_versions`	No
`include_freshness`	No
`include_playbooks`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv4.20.0Sep 2, 2026

addedInput schema / properties / include_playbooks

Added value: +{
+  "default": false,
+  "title": "Include Playbooks",
+  "type": "boolean"
+}

Addedv3.55.0Jun 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations, the description discloses that only reviewed/current knowledge is returned, that superseded/pending/archived items are excluded, that meta.omitted reports {omitted_count, ids, sections, reason} when the budget trims, and that owner-only governance refusal happens before any search or telemetry side effect — a meaningful safety disclosure.

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?

Content is front-loaded and every clause is substantive, but the full Chinese/English duplication roughly doubles the length of a description that is already dense. The information is useful; the delivery is bloated.

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

Completeness5/5

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

Return shape, omission metadata, governance gating, and every parameter are covered, and an output schema exists to carry the response structure. An agent has everything needed to decide and call correctly.

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

Parameters5/5

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

Schema description coverage is 0% for 7 parameters, and the Args block compensates fully: limit default 8 with max 20, token_budget default 2000, include_playbooks v4.20 default False with a 240-char preview cap and <=25% budget ceiling, and collapse_versions' compatibility semantics. This is exactly the added meaning the schema lacks.

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

Purpose4/5

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

It states a concrete verb+resource ("Get a structured Recall Surface v1 payload") and enumerates the payload's components: identity slice, recent activity, relevant knowledge, governance metadata. That distinguishes it from narrow siblings like get_identity_card or get_knowledge_history, though it never names an alternative outright.

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

Usage Guidelines4/5

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

The 'Purpose' line gives an explicit trigger condition: new task, cross-tool handoff, or needing an actionable memory bundle in one shot. No explicit when-not or named alternative, but the aggregate framing implicitly routes simple lookups to the narrower sibling tools.

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