What entity-relation schema and write/query patterns best support cross-session…

Research Question

What entity-relation schema and write-query prompt patterns best support cross-session research provenance and concept reuse for an Artificial Intelligence (AI) research agent using the @modelcontextprotocol/server-memory Model Context Protocol (MCP) memory server, specifically: what entity types and relation types should represent research concepts, item provenance, and cross-item connections; what create_entities, create_relations, and add_observations call patterns enable reliable retrieval in later sessions; and what failure modes of Large Language Model (LLM)-managed knowledge graphs should the schema design protect against?

Findings

Executive Summary

A four-entity schema built around research_item, concept, claim, and method, with tags stored as observations rather than as first-class nodes, is the best fit for the current Model Context Protocol (MCP) server-memory because this knowledge graph, meaning a structured knowledge model that stores entities and typed relations, supports only lexical search, exact-name retrieval, atomic observations, and shallow relation expansion.

The key design choice is to treat the graph as curated archival memory for reusable concepts and propositions, not as a full extraction of every research sentence, because the main failure modes are duplicate entities, schema drift, provenance loss, and lexical recall failure rather than lack of storage capacity.

Reliable reuse depends on three disciplines: canonical prefixed names, a fixed small relation vocabulary, and provenance-rich atomic observations that expose tags and aliases to lexical search.

The write and query patterns can fit within the prompt budget if they encode only those disciplines and cap each completed item to a handful of reusable nodes rather than attempting comprehensive graph capture.

Key Findings

1. The current Model Context Protocol server-memory contract strongly favors a small canonical schema because it offers only lexical substring search over names, entity types, and observations, plus exact-name opening of nodes and adjacent relations.
2. The best default entity set for this repository is research_item, concept, claim, and method, because that set preserves provenance, reusable topics, proposition-level support or contradiction, and recurring techniques without forcing the graph to model every frontmatter field as a separate node type.
3. Tags should remain provenance-rich observations such as tag:knowledge-graph instead of becoming first-class nodes, because the server cannot query by ontology or graph pattern and low-value tag nodes would increase duplication faster than they improve retrieval.
4. A minimum useful relation vocabulary is addresses, states, about, uses_method, supports, contradicts, and extends, because these edges capture provenance and epistemic reuse while avoiding the graph spam created by weak relations such as mentions or related_to.
5. The write path should always be search-first, then create a single item node, then create only 3-5 concept nodes plus a small number of claim and method nodes, because name reuse and node caps are the simplest effective defenses against duplicate entities, orphaned nodes, and schema drift.
6. Provenance and recall both improve when every reusable node carries atomic observation tokens such as provenance:item=<slug>, section:key-finding-2, tag:<canonical-tag>, and alias:<variant>, because those short strings become the server's practical retrieval index.
7. MemGPT and Letta support treating this graph as curated archival memory for reusable concepts and claims rather than as exhaustive storage, because long-term agent memory is useful only when later sessions can pull the right structured context back into the active window at the right time.
8. The major failure modes for an LLM-managed graph in this repository are duplicate entity alignment, schema drift, provenance loss, and lexical recall gaps, and each one is better mitigated by fixed vocabulary and naming rules than by adding more schema complexity.

Assumptions

• None beyond the stated scope and the documented server contract.

Analysis

The decisive constraint in this item is not abstract knowledge-graph theory but the actual retrieval behavior of the Model Context Protocol server-memory, because lexical substring search means that stable names and observation tokens carry most of the retrieval burden.

That is why a richer ontology, first-class tag nodes, or broad weak relations were rejected as the default design: those alternatives increase maintenance cost without giving this server a better query surface, while the external knowledge-graph literature repeatedly shows that alignment and schema-management effort scale badly.

The strongest rival design would be a concept-plus-tag graph with no separate claim nodes, because it is cheaper to write. That rival was rejected because support and contradiction are proposition-level relationships, and collapsing them into concept nodes would blur the difference between a topic and a conclusion.

The other plausible rival would be comprehensive extraction of every key finding sentence. MemGPT, Letta, and the repository's prior memory work all point the other way: useful long-term memory is curated context that can be reactivated later, not maximal archival volume.

Risks, Gaps, and Uncertainties

• The recommended schema is optimized for the current repository scale and the current server implementation, so it may need revision if the corpus grows enough that tags, source nodes, or temporal validity become retrieval-critical.
• The evidence base supports the failure modes strongly, but the exact node cap of 3-5 concepts per item remains a practical design judgment rather than an experimentally benchmarked threshold.
• The server has no native multi-hop traversal, temporal reasoning, or confidence-aware ranking, so some later retrieval failures may remain even with good schema hygiene.

Open Questions

• At what corpus size does tag:<canonical-tag> stop being a sufficient observation-level recall surface and become worth modeling as a first-class node?
• Would a later version of the repository benefit from adding source nodes for external papers and URLs, or would that only recreate bibliographic metadata already stored elsewhere?
• How much retrieval quality would improve if the server gained hybrid lexical plus vector search while keeping the same graph schema?

sources

• [x] Model Context Protocol server-memory README
• [x] Model Context Protocol server-memory source code
• [x] Packer et al. (2024) MemGPT: Towards LLMs as Operating Systems
• [x] Letta (2025) Agent Memory: How to Build Agents that Learn and Remember
• [x] Luo et al. (2024) Unifying Large Language Models and Knowledge Graphs: A Roadmap
• [x] Wang et al. (2023) Knowledge Graph Prompting for Multi-Document Question Answering
• [x] Hitzler et al. (2024) Accelerating Knowledge Graph and Ontology Engineering with Large Language Models
• [x] Cheng et al. (2025) EasyEA: Large Language Model is All You Need in Entity Alignment Between Knowledge Graphs
• [x] Anonymous et al. (2024) Entity Alignment with Noisy Annotations from Large Language Models
• [x] Ahrens (2017) How to Take Smart Notes
• [x] Mitchell (2026) Knowledge linking: building a connected research corpus via explicit cross-references and a knowledge graph
• [x] Mitchell (2026) Agent Memory Management and Context Injection
• [x] Mitchell (2026) Knowledge Representation for Agent Context: LSE, Knowledge Graphs, Concept Maps, and Document Compression for Large-Scale Context Management
• [x] Mitchell (2026) Is knowledge scaffolding an established concept within context engineering for Large Language Models and AI agents, and how is it defined and implemented?