Engram

Overview Schema Source Related Servers Score Discussions Admin

get_recall

Retrieve a structured, actionable memory bundle for new tasks or cross-tool handoffs. Includes identity slice, recent activity, relevant knowledge, governance metadata, and optional playbook pointers.

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.

注意：该聚合视图可能组合多类知识和最近上下文，因此治理开启时仅 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: 是否折叠版本链到当前 HEAD。 / Collapse version chains to current heads.
    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).

Input Schema

TableJSON 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

TableJSON 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.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden, and it delivers substantial behavioral detail. It discloses owner-only access when governance is enabled, explains that non-owners are refused before any search or telemetry side effect occurs, and details playbook pointer bucket constraints including max items and budget share.

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

Conciseness4/5

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

The description is well structured and front-loaded: purpose, usage, behavioral notes, then args. The bilingual duplication makes it longer than strictly necessary, but every substantive point earns its place given the absence of schema descriptions and annotations.

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?

The description is complete for a 7-parameter tool with no annotations: it covers purpose, invocation context, access control, side-effect behavior, and each parameter. Since an output schema exists, the return value does not need explanation, and nothing critical appears missing for correct invocation.

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?

The input schema has zero description coverage for all seven parameters, and the description fully compensates by documenting each argument with defaults, types, constraints, and behavior. It even adds important detail such as limit max 20, token_budget default 2000, and the precise playbook inclusion rules for include_playbooks.

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?

The description clearly identifies the tool as returning a structured Recall Surface v1 payload: a memory bundle containing identity, recent activity, relevant knowledge, and governance metadata. It positions the tool as an aggregate view, which distinguishes it from narrower siblings like get_identity_card, get_relevant_knowledge, and get_recent_context.

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 description explicitly states when to call it: on new tasks, cross-tool handoffs, or when a single executable memory bundle is needed. It gives clear context but does not explicitly name alternatives or state when not to use it, so it misses the full when-not/alternative guidance required for a 5.

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