SmartMemory
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| add_memoryA | Store a fact in semantic memory using RDF triple notation. CRITICAL - ANTI-HALLUCINATION RULES: ❌ NEVER suggest example facts and then add them as if user confirmed ❌ NEVER assume user response validates your examples ❌ NEVER invent names, relationships, dates, or any entities ❌ NEVER add facts based on your assumptions or knowledge ✓ ONLY add facts that user EXPLICITLY and UNAMBIGUOUSLY stated ✓ If unsure what user meant, ASK for clarification before adding ✓ If user says 'I don't know', do NOT add anything Example of INCORRECT behavior (HALLUCINATION): User: 'Who is Alice's father?' You: 'I don't know. Can you tell me? Example: :Alice :hasFather :Bob' User: 'ok' [or any vague response] You: add_memory(':Alice :hasFather :Bob') ← WRONG! User never said this! Example of CORRECT behavior: User: 'Alice's father is Bob' You: add_memory(':Alice :hasFather :Bob') ← CORRECT! What happens when you add a fact:
Supported predicates:
Format: ':Subject predicate:name :Object' Examples: add_memory(':User foaf:knows :Alice') add_memory(':User :isFriendOf :Bob') # Custom predicate add_memory(':Charlie schema:worksFor :AcmeCorp') Note: Use ':User' for current user, ':' prefix for all user entities. |
| query_memoryA | Query the semantic memory graph using SPARQL. Returns ONLY facts that are formally proven (either explicitly added by user or inferred by SPARQL rules). CRITICAL - Your Role as Assistant:
When to use:
Query Guidelines:
Example workflow 1 (Simple check):
Example workflow 2 (Proactive rule learning):
Output format:
|
| search_entityA | Search for entities in the knowledge graph by name or label. Returns matching entities with their types and key properties. |
| list_rulesB | Lists all available SPARQL inference rules, their sources, and their status. |
| load_custom_ruleA | Loads a new custom SPARQL CONSTRUCT rule from text. The rule should be a SPARQL CONSTRUCT query that infers new triples. PREFIX declarations are optional - common prefixes (rdf, schema, foaf, etc.) will be auto-added if not present. Example rule content: CONSTRUCT { ?person rdf:type :Engineer . } WHERE { ?person schema:worksFor :Company . } |
| verify_inferenceA | Verify if a fact is FORMALLY PROVEN in the knowledge graph. This is THE KEY TOOL for collaborative LLM-Formal reasoning. WHEN TO USE (CRITICAL): ✓ BEFORE stating a deduction as fact ✓ When user asks 'Is X true?' or 'Does Y hold?' ✓ After making a soft reasoning step ✓ To distinguish your intuition from formal proof WORKFLOW:
Returns:
Example: verify_inference(subject=':Alice', predicate='foaf:knows', object=':User') → Returns proof chain if fact is formally established |
| suggest_ruleA | IMPORTANT: USER APPROVAL REQUIRED / APPROBATION REQUISE Allows the LLM to propose SPARQL rules to formalize reasoning patterns. CRITICAL WORKFLOW:
WHEN TO USE: ✓ After verify_inference() returns 'not proven' for logical deduction ✓ When user explicitly states a rule (e.g., 'friends know each other') ✓ When detecting recurring patterns in conversation ✓ To convert YOUR soft reasoning into FORMAL guarantees WORKFLOW EXAMPLE:
CRITICAL - DO NOT BYPASS THIS TOOL: ❌ NEVER edit .rq files directly ❌ NEVER create rules outside this workflow ✓ ALWAYS use suggest_rule() → user approves → system activates Best Practices:
Rule goes to PENDING - User must approve! |
| get_pending_verificationsA | List all pending verifications (uncertain inferences that need user confirmation). Returns a list of inferred triples with their confidence scores and source rules. Use verify_inference tool to accept or reject them. |
| get_pending_rulesA | Get list of rules proposed by the LLM that are awaiting user approval. Use this after suggesting a rule to show the user what needs approval. |
| approve_ruleA | Approve a pending rule and activate it in the inference engine. The rule will start inferring facts immediately. SYSTEM: DO NOT CALL THIS AUTOMATICALLY. WAIT FOR USER INPUT.
You CANNOT verify/approve your own rules. You must display the rule using |
| reject_ruleA | Reject a pending rule. It will not be activated and will be removed from pending list. |
| get_graph_statsC | Retrieve statistics about the knowledge graph. |
| load_documentA | Load a document (PDF, Text, Markdown) into the knowledge graph and automatically extract business rules. Usage:
What it does:
Options:
|
| forget_memoryA | Remove a fact from semantic memory, including its provenance metadata. CRITICAL RULES: ❌ NEVER remove facts without explicit user instruction ❌ NEVER remove facts that are foundations for other inferences (check first with query_memory) ✓ Use when user explicitly says 'forget', 'remove', 'that's wrong', 'delete that' ✓ Always confirm with user before removing What happens when you forget a fact:
Format: ':Subject predicate :Object' Examples: forget_memory(':User foaf:knows :Alice') forget_memory(':Bob schema:worksFor :AcmeCorp') |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| remember-fact | Store a new fact or piece of information in semantic memory |
| query-knowledge | Search for information in semantic memory |
| add-custom-rule | Create a custom inference rule to automatically derive new knowledge |
| show-stats | Show statistics about the knowledge graph (how much is known, inference activity, etc.) |
| verify-inferences | Review and confirm/reject uncertain inferences that need user verification |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Most tools are clearly distinct, but load_custom_rule and suggest_rule both add SPARQL rules with different approval paths, creating ambiguity. Additionally, verify_inference's description mentions accepting/rejecting pending verifications, overlapping with get_pending_verifications and approve_rule.
All names use snake_case, but retrieval verbs are mixed (list, get, search, query) and rule-related tools use inconsistent actions (load, suggest, approve, reject). The naming is readable but not fully predictable.
14 tools is within the ideal 3-15 range and each serves a distinct role in the memory and rule management workflows. The count is well-scoped for the server's purpose.
Core memory operations (add, remove, query, search) and rule lifecycle (suggest, approve, reject, list) are covered. Minor gaps include no explicit update/merge operation for facts and potential confusion around handling rules extracted by load_document.