Skip to main content
Glama
Sign In
Engram

Engram

by Patdolitse
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

doctor

Read-onlyIdempotent

Run a health check on the Engram memory system to detect data fragmentation, stale knowledge, conflicting decisions, and identity issues.

Instructions

记忆系统自诊断。 / Memory system self-diagnosis.

用途：检查 Engram 记忆系统健康状态，发现潜在问题（数据碎片、过期知识、冲突决策、
身份层异常等）。这是 MCP doctor；CLI 冲突视图请用 ``engram conflicts list``。
Purpose: Run a comprehensive health check on the Engram memory system —
detects data fragmentation, stale knowledge, conflicting decisions, identity
issues, and more.

Args:
    output_format: "markdown" 或 "json"。 / "markdown" or "json".

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": "doctor"
  }
}

Input Schema

NameRequiredDescriptionDefault
output_formatNomarkdown

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.29.4

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description adds what the check actually inspects ('data fragmentation, stale knowledge, conflicting decisions, identity issues'), which is genuine context beyond the annotations. It doesn't describe report shape or runtime cost, but the output schema exists for that.

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 the one-line purpose, then use case, then parameters — a clean shape. It is roughly doubled in length because every sentence is given in both Chinese and English, which is wasteful for a single-locale reader but consistent and still scannable.

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 the description needn't document return values, and it covers purpose, scope and the single parameter's allowed values. The only omission is practical guidance about when in a workflow to invoke it, which is minor for a one-parameter read-only diagnostic.

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% and the schema has no enum, so the description carries the burden by naming the two legal values ('markdown' or 'json'). That is real added meaning beyond the schema, though it omits any note about the default or output size differences.

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 ('Run a comprehensive health check on the Engram memory system') and enumerates the problem classes it detects (fragmentation, stale knowledge, conflicting decisions, identity issues). None of the sibling tools are diagnostic, and it explicitly distinguishes itself from the CLI conflicts view, so an agent can place it without ambiguity.

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 plus the explicit routing note ('this is MCP doctor; for the CLI conflict view use engram conflicts list') gives clear context for when to select it and what the adjacent alternative is. It stops short of stating triggering conditions such as running it after a session or when recall results look inconsistent.

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