A knowledge graph management server for Azure Functions that stores and retrieves entities and relations in a central memory system using Azure Table Storage
Central Memory MCP demonstrates reasonable structure with 4 well-intentioned tools, but falls short of production-grade quality in several critical areas. All tools have descriptions and most have input schemas with type information, placing it in the 'Fair' range. However, parameter descriptions are inconsistent, output schemas are undocumented, error handling lacks actionable recovery guidance, and the use of both GUID-based and legacy name-based parameters creates ambiguous tool interfaces. The schema is visible and mostly typed, but several parameters lack descriptions entirely or have generic descriptions. The upsert_relation tool particularly suffers from confusing parameter naming (From/To vs FromEntityId/ToEntityId) and optional-vs-required ambiguity.
Gets all relations originating from a specific entity.
Reads the entire knowledge graph (entities and relations) for a workspace.
Creates or updates an entity in the knowledge graph.
Creates or updates a relation between two entities in the knowledge graph.
upsert_relation uses confusing dual-parameter pattern (FromEntityId/ToEntityId vs From/To) without clear mutual-exclusivity documentation. Code shows runtime fallback logic, but descriptions do not explain when to use each or that one is 'legacy'. LLMs will pass both or pick wrong variant.
Output schemas are not documented anywhere in the tool definitions. LLMs cannot predict what fields to expect in responses (success, id, workspace, name, etc.). This violates the pattern:tool-description requirement that LLMs know what the tool returns.
Error responses return generic messages like 'Invalid entity payload' without actionable recovery steps. No guidance on what to try next, does the LLM retry, call a different tool, or ask the user? Violates pattern:recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 65 | - | v1 |
read_graph and get_entity_relations lack pagination parameters (limit, offset, cursor). No indication of result limits. A workspace with thousands of entities could return massive responses, blowing context windows and inviting hallucination.
Parameters use inconsistent naming conventions. 'workspaceName' (camelCase), but also 'FromEntityId', 'ToEntityId', 'RelationType' (PascalCase). UpsertEntityRequest uses 'WorkspaceName' while function parameter uses 'workspaceName'. This inconsistency will confuse LLMs about field names.
Several parameters lack descriptions entirely: UpsertRelationRequest.FromEntityId says 'The GUID of the source entity' but does not explain that it is optional and has a legacy fallback (From). Undescribed parameter relationships force LLMs to reason about code logic.