Skip to main content
Glama
Sign In
Engram

Engram

by Patdolitse
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_relevant_knowledge

Read-onlyIdempotent

Automatically retrieves the most relevant past lessons for a project path when you don't know what to search for, filtering results by the project's tech stack.

Instructions

按项目路径自动推荐最相关的经验教训（无需搜索词）。 / Automatically recommend the most relevant lessons for a project path, without search keywords.

**Lifecycle: retrieval** — 在对话中需要项目相关的历史知识时调用。
Lifecycle: retrieval — call mid-conversation when project-relevant past knowledge is needed.

用途：你知道当前项目路径但不知道该搜什么词时调用，Engram 根据项目技术栈自动筛选。
Purpose: Call when you know the current project path but not the right search terms; Engram filters by project tech stack.

注意：如果用户给了明确搜索词，用 search_knowledge 更直接。只返回已审核且当前有效的经验（待审、被取代、已归档的不返回）。
Note: If the user provides explicit search keywords, search_knowledge is more direct. Returns reviewed, current lessons only (no pending, superseded or archived items).

Args:
    project_folder: 当前项目文件夹路径。 / Current project folder path.
    limit: 最多返回多少条（默认 8）。 / Maximum number of items to return (default 8).
    include_freshness: 为每条结果附加 freshness/新鲜度提示（默认 False，保持旧输出不变）。 / Attach a per-item freshness hint (default False; output is unchanged when omitted).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_folder": "<project_folder>"
    },
    "name": "get_relevant_knowledge"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
project_folderYes
include_freshnessNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.6.2
  2. Removedv4.6.1
  3. Changed1 schema field changedv3.48.0
    • addedInput schema / properties / include_freshness
      Added value: +{
+  "default": false,
+  "title": "Include Freshness",
+  "type": "boolean"
+}
  4. Addedv3.29.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare a safe read (readOnlyHint, idempotent, non-destructive), so the bar is lower, yet the description still adds real behavior: filtering is by inferred project tech stack, and only reviewed/current lessons are returned while pending, superseded and archived are excluded. It also notes include_freshness leaves output unchanged when omitted, which prevents surprises. Return shape is left to the output schema, which is acceptable.

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?

Front-loaded with purpose and lifecycle, then usage, then caveats, then args — a clean hierarchy. The full bilingual duplication doubles the token cost for any single-language reader, which is the main inefficiency, though the added lines are at least the highest-value ones.

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

Completeness4/5

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

With an output schema present, return values need no explanation, and the three-parameter surface is fully documented. What remains unexplained is how the project tech stack is inferred and what happens if the folder path is unrecognized — minor given the retrieval-only, read-only nature of the call.

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

Parameters4/5

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

Schema description coverage is 0%, so the description carries the full burden and mostly does: every parameter is defined with meaning and default value (project_folder as current project path, limit default 8, include_freshness default False with its effect on output). It stops short of stating path format expectations (absolute vs relative) or behavior when the path is unknown.

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?

States a specific verb and resource ('recommend the most relevant lessons for a project path') plus the distinguishing mechanism ('without search keywords'). The 'Purpose' paragraph further contrasts it with search_knowledge, so an agent can separate it from the sibling without reading either schema.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('call mid-conversation when project-relevant past knowledge is needed') and an explicit exclusion with named alternative ('If the user provides explicit search keywords, use search_knowledge more directly'). This is the when/when-not/alternative triad at full strength.

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

Deploy Server

Other Tools