Engram

by Patdolitse

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v4.14.1
Disambiguation4/5
Most tools have distinct purposes, but there are multiple 'get' tools (get_user_context, get_recall, get_resume_brief, etc.) whose boundaries could be confused. However, descriptions provide clear guidance on when to use each, so overall ambiguity is low.
Naming Consistency4/5
Tool names follow a fairly consistent verb_noun snake_case pattern (add_*, get_*, update_*, etc.). Exceptions like 'doctor' and 'memory_store' deviate slightly, but the overall naming is predictable and readable.
Tool Count5/5
17 tools is well-scoped for a memory/knowledge management server. The number covers all necessary operations (write, read, search, session management, diagnostics) without being overwhelming.
Completeness4/5
The tool surface covers most core operations: creating, reading, searching, and updating knowledge. Minor gaps include lack of explicit delete or update tools for individual lessons/decisions, but versioning and superseding partially compensate.
Average 4.3/5 across 17 of 17 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 14 of 14 community issues answered or closed in the last 6 months
- 485 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It states 'writeback lifecycle' implying a write operation, but lacks details on side effects, duplicate handling, authorization needs, or return behavior. The output schema exists but is not mentioned. Sufficient for basic understanding 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with headings and clear separation of purpose and lifecycle. Bilingual adds length, but each sentence serves a purpose. Front-loaded with core action. Could be more concise if monolingual, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Moderate complexity tool with 10 params and output schema. Description covers usage, lifecycle, and most params, but misses two parameters (project_folder, user_confirmed) and does not mention output schema or return values. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description partly compensates by explaining 8 out of 10 parameters (missing project_folder and user_confirmed). Domain parameter gets extra context (comma-separated labels). Baseline for 0% is low, but description adds meaningful value for most params, earning above baseline.
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?
Description clearly states tool records a single lesson learned, with verb 'record' and resource 'lesson learned'. It distinguishes from extract_session_insights but does not explicitly differentiate from sibling tools add_decision and add_playbook, though the domain (lesson vs decision/playbook) is implied.
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?
Provides explicit when-to-use (user explicitly states a lesson) and when-not-to-use (if session summary, use extract_session_insights). However, it does not mention when to use add_decision or add_playbook instead, which limits comprehensive guidance against all siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behaviors. It mentions storage as files and retrieval via triggers but omits side effects, overwrite behavior, or authorization needs. This is insufficient for a tool with 17 parameters.
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?
The description is bilingually verbose and includes repeated patterns, but it is front-loaded with purpose and organized with parameter list. Could be more concise.
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?
For a complex tool (17 params, output schema exists), the description covers purpose, usage context, parameter meanings, and storage model. Minor gaps: no error handling or validation details, but overall sufficient.
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?
The schema has 0% description coverage, but the description provides detailed explanations for many parameters (e.g., triggers as comma-separated keywords, steps_json format). This adds significant meaning beyond mere names and defaults.
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 states the tool records a structured multi-step procedure as a playbook, distinguishing it from siblings like add_decision or add_lesson. The verb 'record' and resource 'playbook' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (after completing a multi-step process) but does not explicitly exclude cases or compare to alternatives. Sibling tools are not mentioned, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool only reads data and does not auto-load into new sessions, which is key behavioral information. It does not mention side effects, but as a read operation, that is sufficient.
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 structured with purpose and usage sections and is reasonably concise. The bilingual text adds length but each sentence provides value. It could be slightly more compact by dropping repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain the return format. It misses documenting the 'project_folder' parameter. For a tool that recovers context, the description covers the main use case but lacks completeness on parameters and return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for the 'tool' and 'limit' parameters (with defaults and purpose), but the 'project_folder' parameter in the input schema is completely undocumented. Given 0% schema description coverage, the description partially compensates but misses one parameter.
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 states the verb 'retrieve' and resource 'most recent conversation context', and specifies the scenario of context loss after tool restart or session disconnect. It distinguishes purpose from sibling tools like get_recall or get_user_context by focusing on recent context recovery.
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 tells when to use the tool (after context loss) and clarifies it does not auto-load. However, it does not mention when not to use it or reference specific sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses types of issues detected (fragmentation, stale knowledge, etc.) but does not explicitly state read-only nature or other behavioral traits like side effects or auth requirements.
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?
Bilingual structure is clear: purpose, detection list, alternative mention. Slightly redundant between languages but front-loaded and efficient overall.
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?
Given simple tool (one param, no required, has output schema), description covers purpose and parameter. Could add example or mention non-destructiveness, but adequate for context.
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?
Only parameter 'output_format' with default 'markdown'. Description lists allowed values ('markdown' or 'json'), which the schema (only title, type, default) lacks. Adds meaningful semantic choice.
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?
Clearly states verb 'check' (implied) and resource 'Engram memory system health'. Lists specific issues detected. Distinguishes from sibling CLI command via explicit alternative.
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?
Describes when to use (health check, detect issues) and provides alternative for CLI conflict view. Lacks explicit exclusion of other sibling tools but context implies diagnostic vs retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states the tool is read-only ('读取', 'Read'), and specifies the scope ('只含该项目的历史'), implying no side effects. Missing details like authentication or rate limits, but these are minor for a read operation. The description is transparent enough for safe selection.
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 with bilingual sections and clear headings (用途/目的, 注意/Note). It is concise (~100 words) and front-loads the purpose. A small improvement could be removing redundant phrasing, but overall it is efficient and easy to scan.
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?
Given the tool has only one parameter, no annotations, but an output schema exists, the description adequately covers purpose, usage guidelines, parameter semantics (minimally), and behavioral traits. It mentions what the tool contains (history of that project) but does not describe return structure, which output schema likely provides. It is sufficiently complete for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description only says '项目文件夹路径。 / Project folder path.' which adds minimal meaning beyond the schema's type string. It does not clarify expected format (absolute/relative), or provide examples. This is insufficient for a parameter-rich tool.
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 explicitly states the tool reads a knowledge snapshot for a specific project and contains only that project's history, using specific verbs and resource. It also distinguishes from siblings like get_user_context and save_project_snapshot, clarifying its scope.
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?
Provides clear when-to-use guidance: '想了解某个项目之前的技术栈、已知问题、协作次数时调用' (Call when you need a project's previous tech stack, known issues, notes, or collaboration history). It also explicitly mentions two alternatives: get_user_context for user-level context and save_project_snapshot for writing, making the usage context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It discloses lifecycle (writeback), routing, batch vs single mode, and constraints (playbook not in batch). Does not detail overwrite behavior but implies additive persistence.
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?
Well-structured with Args list, bilingual but not overly verbose. Each sentence adds value. Could omit duplicates between languages but still acceptable.
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?
Given tool complexity (router, batch/single, varying formats), description covers routing, usage modes, and param details for most params. Output schema exists so return values not needed. Missing param explanations for two fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description explains kind, content_json format per type, source_tool, and items_json for batch, but omits project_folder and user_confirmed parameters.
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 defines the tool as a unified write endpoint that routes to specialized tools based on 'kind', distinguishing it from siblings like add_lesson, add_decision, add_playbook.
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?
Explicitly states when to call (lifecycle writeback) and provides guidance on alternatives (specialized tools) and advantages (callers don't need Engram taxonomy).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes as a write operation but lacks details on side effects, permissions, or update vs. overwrite behavior. With no annotations, more transparency would be beneficial.
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?
Bilingual but each sentence adds value; no fluff, but slightly redundant in both languages. Efficient overall.
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?
Covers purpose, usage, and parameters. With output schema present, return value not needed. Lacks potential error handling or prerequisites, but adequate for a simple write tool.
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 has 0% description coverage, but description adds meaning for both parameters: project_folder path and data_json fields (title, tech_stack, known_issues, notes).
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?
Clearly states it writes or updates a project snapshot, distinguishes from read operation get_project_context.
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?
Explicitly says when to use (save/update) and when not (use get_project_context for reading), providing clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the lifecycle as retrieval (read-only), explains parameter effects (e.g., truncation with max_field_chars, freshness hints), and implies non-destructive behavior. It does not explicitly state auth or rate limits, but for a search tool the transparency is good.
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 front-loaded with a summary and lifecycle, then usage guidance, then parameter details. It is well-structured but somewhat verbose due to bilingual text. Every sentence is useful, but conciseness could be slightly improved.
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?
Given the tool's complexity (7 parameters, no annotations, output schema exists), the description covers key behaviors: parameter explanations, truncation, freshness hints. It lacks error handling details but is sufficient for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does so for most (query, scope, limit, filters_json with example, include_freshness, max_field_chars) but omits project_folder, leaving a gap. The explanations add value beyond the schema (e.g., filters_json keys).
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 states the tool searches a knowledge base of lessons, decisions, and playbooks by keyword. It distinguishes from siblings like get_relevant_knowledge (for project path without query) and explore_knowledge (for existing ID), making the purpose unambiguous.
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?
The description explicitly says when to call this tool (when user asks to find knowledge or recalls a procedure) and when not to, providing alternative tools (get_relevant_knowledge, explore_knowledge). This gives clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses owner-only behavior when governance enabled, non-owners refused before side effects, and composite nature. Lacks details on error handling or rate limits, but adequate for read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with bold purpose, a critical note, then clear Args list. Bilingual but compact. Every sentence adds value; no redundancy or filler.
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?
Describes return content (identity, recent activity, knowledge, governance) and governance behavior. Output schema exists to detail return structure. Lacks explanation of parameter interactions (e.g., empty vs populated project_folder), but sufficient for an agent.
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%, but description adds meaningful semantics for all 6 parameters: purpose, defaults, and constraints (e.g., limit max 20, token_budget default). Could clarify boolean behavior (include_freshness, collapse_versions) further.
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?
Clearly states the tool retrieves a structured Recall Surface v1 payload combining identity, recent activity, knowledge, and governance metadata. Distinguishes from siblings by specifying composite nature and use for new task/handoff.
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?
Explicitly says when to use (new tasks, cross-tool handoff needing a single memory bundle). Could explicitly name alternatives (e.g., 'for just identity use get_identity_card'), but the purpose and sibling list provide implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output format (wrapped in <engram-resume priority='high'>), lifecycle (session start), and optional structured packs. It could be more explicit about read-only nature and potential side effects, but overall provides good behavioral context.
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 with sections for purpose, lifecycle, and arguments. Key information is front-loaded. It is slightly long but each section serves a purpose. Minor redundancies in bilingual text could be trimmed.
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?
Given the tool's complexity (6 params, output schema exists), the description covers the main use cases, parameter details, lifecycle, and output format. It lacks mention of error handling or behavior for invalid project_folder, but overall provides sufficient context 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?
Schema coverage is 0% with no descriptions in the schema. The description fully explains each of the 6 parameters, including defaults, behavior (e.g., token_budget as soft cap), and the effect of include_resume_pack and include_agent_context_pack. This fully compensates for the schema's lack of descriptions.
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 states it returns a cross-session, cross-tool resume brief including identity, project state, daily log, recent context, lessons/decisions, and suggested docs. This specific verb-resource combination distinguishes it from sibling tools like get_recent_context or get_daily_log.
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 provides explicit usage context: call at session start, before first user message, or when user indicates continuing prior work. It gives example user phrases. However, it lacks explicit when-not-to-use or alternatives for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool updates identity fields, details field-specific keys, and mentions source_tool for provenance. It does not discuss idempotency, auth, or side effects, but the mutation behavior is evident. The level of detail compensates for the lack of annotations.
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 front-loaded with purpose and structured into clear sections. However, bilingual text (Chinese and English) doubles the length. Every sentence adds value, but it could be more concise if it used only one language.
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?
Given three parameters and no annotations, the description covers the input thoroughly. An output schema exists (according to context signals), so the description need not explain return values. It adequately addresses the complexities of field management.
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%, but the description thoroughly explains each parameter: field lists valid values, updates_json is described as a JSON string, and source_tool is for provenance. Additionally, it provides exhaustive field-specific keys for each valid field value, which adds immense meaning beyond the schema.
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 states that the tool updates one identity field, listing the specific fields (profile, preferences, trust_boundaries, work_style, quality_standards) and their sub-keys. It distinguishes the tool from siblings like add_decision, add_lesson, etc., which have different purposes.
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: 'Call when changing profile, preferences, trust_boundaries, work_style, or quality_standards.' It also provides a note about valid keys and managing sensitive-field boundaries. Missing explicit when-not-to-use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that the tool reads a file, specifies the exact file path, and describes the content structure (timestamped entry with lesson/decision counts and summary). It implicitly assures read-only behavior, though an explicit statement about lack of side effects would push it to 5.
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 structured with a purpose statement, background, usage guidance, and parameter list. It is front-loaded and each sentence serves a purpose. The bilingual duplication is slightly redundant but acceptable; overall it's efficient.
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?
Given the simple two-parameter schema and the presence of an output schema (not shown), the description covers all needed aspects: what the tool does, how it works, when to use it, and what the file contains. It complements the sibling 'wrap_up_session' well. No gaps identified.
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 coverage is 0%, but the description provides clear meanings for both parameters: project_folder (folder path) and date (ISO format, optional, defaults to today). This adds value beyond the bare schema. A minor improvement would be to include an example or constraints, but it's already sufficient.
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 states the verb 'read', the resource 'project daily log', and distinguishes it from sibling 'search_knowledge' by noting it provides a faster, glance-able timeline. The bilingual text reinforces the purpose.
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?
Explicitly states when to call ('when a new session needs a quick overview'), provides a comparison to an alternative ('faster than search_knowledge'), and explains the file location and content format, leaving no ambiguity about appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool follows lifecycle 'retrieval', filters by tech stack, and includes a parameter include_freshness that attaches a freshness hint. It does not mention side effects, but as a retrieval tool this is acceptable. The response format is covered by the output schema.
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 clear and well-structured, using bilingual text and bullet points for parameters. While it could be slightly more concise by removing redundant phrasing, it remains efficient and front-loads key information.
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?
Given the tool has 3 parameters, an output schema, and no nested objects, the description provides sufficient context: purpose, usage, lifecycle, and parameter details. It could mention handling of invalid project paths, but that is not critical for selection and 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?
Schema description coverage is 0%, so the description must compensate. It explains all three parameters: project_folder (current project path), limit (max items, default 8), and include_freshness (attach freshness hint, default false). This adds meaning beyond the schema's type and default values.
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 states the tool's purpose: automatically recommend relevant lessons for a project path without search keywords. It provides both Chinese and English explanations and distinguishes from the sibling tool search_knowledge by noting it's for when the project path is known but search terms are not.
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?
The description explicitly provides usage guidelines: call when you know the project path but not search terms, and if the user provides explicit keywords, use search_knowledge instead. This helps the agent decide when to invoke this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that old decisions are automatically superseded when the same question gets a different choice, and allows explicit supersedes. It also mentions lifecycle: writeback. However, it does not discuss any side effects, authorization, or persistence, though these may be implicit.
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 with headers and bullet points, but it is somewhat verbose, repeating lifecycle information and using two languages. Every sentence adds value, but it could be slightly more concise without losing clarity.
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?
Given 12 parameters (2 required), no enums, no nested objects, and an output schema exists, the description thoroughly explains each parameter, the decision thread, and usage context. It is complete and leaves no significant gaps.
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%, so the description must compensate. It provides a thorough 'Args' section documenting all 12 parameters with clear explanations in both Chinese and English, including defaults and optionality.
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 states the tool records a key decision when the user explicitly chooses an option, with examples like 'we decided to use X'. It distinguishes the tool from extract_session_insights and explains the decision thread behavior, providing a specific verb ('record') and resource ('key decision').
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?
The description explicitly says when to call: when the user explicitly makes a decision. It also provides a clear exclusion: if the user gives a session summary for automatic extraction, use extract_session_insights instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses file writing (exports/identity_card.md) and authorization (refused for non-owners when governance enabled). No annotations provided, so description carries full burden; it does well but could mention side effects or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences in English and Chinese, plus a note. Front-loaded with action and purpose, no wasted words.
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?
Describes what is exported (identity, work style, quality standards, lessons), conditions, and alternative. Output schema exists for return format. Complete for a simple tool.
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?
No parameters exist, schema coverage is 100%. Description correctly omits parameter details; baseline 4 for zero-parameter tools.
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 states it exports a portable AI identity card as Markdown, specifies the file path, and distinguishes from get_user_context for runtime context. The verb 'Export' and resource 'portable AI identity card' are specific and unique among siblings.
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?
Explicitly tells when to use (when another AI tool needs a self-contained summary) and when not (for runtime context, use get_user_context). Provides clear alternatives and conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: quick tier is pure JSON reads (low latency), standard adds quality/domains/lessons, full includes conflict detection and auto-sync side effects. It also notes that standard skips expensive reconciliation.
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 with bilingual text, bullet points, and clear sections. It is slightly lengthy but every sentence adds value; could trim some repetition but overall effective.
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?
Given the four parameters, no annotations, and the presence of an output schema, the description covers all necessary aspects: purpose, usage context, parameter details, tier behavior, and side effects. It is complete for an AI agent to correctly select and invoke the tool.
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 coverage is 0%, but the description explains all four parameters in detail: project_folder (optional), level (tiers and defaults), token_budget (priority-based clipping), and user_prompt (playbook matching). This adds significant meaning beyond the bare schema.
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 states the tool retrieves user context at conversation start, with three tiers (quick/standard/full) each detailed. It distinguishes from sibling tools like get_identity_card or get_project_context by specifying it provides comprehensive context including preferences, quality, lessons, etc.
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 says to call at the start of each conversation and notes the standard tier suffices for most cases, with full tier reserved for explicit user requests. However, it does not directly compare with sibling tools or state when to use them instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully assumes the behavioral disclosure burden. It details the auto-extraction of playbooks (with confidence levels and disable option), the conditional snapshot saving, and the return value structure including playbook_draft. All behavioral aspects are transparent.
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 comprehensive but somewhat lengthy, using bilingual text and multiple sections. Key information is front-loaded, and the structure is good, but could be slightly more concise without losing value.
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?
Given the tool's complexity (8 parameters, side effects, output fields), the description covers purpose, usage guidelines, parameter semantics, behavioral nuances (auto-extraction, optional snapshot), and return value details. No output schema is needed for completeness as the description provides adequate context.
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?
Despite 0% schema description coverage, the description provides detailed explanations for each parameter in the Args section, including optional parameters and their effects (e.g., project_folder omitted means no snapshot, project_title needed only for first snapshot). This fully compensates for the schema gap.
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 states the tool's purpose: 'Wrap up a session in one step: extract knowledge, detect playbooks, and save a project snapshot.' It explicitly contrasts with sibling tools extract_session_insights and save_project_snapshot, providing clear differentiation.
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?
The description gives explicit lifecycle guidance ('Lifecycle: session-end — call at conversation end') and directly states when to use this tool vs alternatives ('Use extract_session_insights when you only want extraction, and save_project_snapshot when you only want to save a project snapshot.').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![piia-engram MCP server](https://glama.ai/mcp/servers/Patdolitse/piia-engram/badges/card.svg)](https://glama.ai/mcp/servers/Patdolitse/piia-engram)

Score Badge

Copy to your README.md:

[![piia-engram MCP server](https://glama.ai/mcp/servers/Patdolitse/piia-engram/badges/score.svg)](https://glama.ai/mcp/servers/Patdolitse/piia-engram)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Patdolitse/piia-engram'

If you have feedback or need assistance with the MCP directory API, please join our Discord server