Skip to main content
Glama

add_memory

Store an explicitly confirmed fact as an RDF triple in the knowledge graph, triggering inference rules. Only adds facts the user stated, preventing hallucination.

Instructions

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:

  1. Fact is stored with confidence=1.0 (explicit user fact)

  2. SPARQL inference rules automatically run in background

  3. New facts may be inferred (e.g., symmetry, transitivity)

  4. Check get_pending_verifications() for inferred facts needing approval

Supported predicates:

  • foaf:knows, foaf:friend - Social relationships

  • schema:worksFor, schema:colleague - Work relationships

  • rdf:type - Classifications

  • :customPredicate - Any custom predicate (user namespace)

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputYesRDF triple: ':Subject predicate :Object'
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 side effects: facts stored with confidence=1.0, SPARQL inference rules running automatically, and potential inferred facts requiring approval via get_pending_verifications(). This goes beyond the simple 'store a fact' statement, though it doesn't mention error cases or permission 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?

The description is long but well-structured with clear headers, critical rules, an incorrect-vs-correct example, and a supported-predicates list. Every section serves a purpose (especially the anti-hallucination guidance), though it could arguably be tightened slightly 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?

For a tool with no output schema and only one parameter, the description is remarkably complete. It covers the purpose, the exact input format with examples, when it should and shouldn't be used, what happens after invocation (confidence, inference), and related tools to check afterward. This fully equips an agent to use the tool correctly in 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?

Though the schema covers 100% of parameter semantics (the single 'input' parameter is described as an RDF triple), the description adds significant extra meaning: supported predicates (foaf:knows, schema:worksFor, rdf:type, custom), format examples, notes on the ':User' and ':' prefixes, and the triple structure. This meaningfully exceeds the schema's basic 'RDF triple: ':Subject predicate :Object''.

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 opens with a specific verb and resource: 'Store a fact in semantic memory using RDF triple notation.' It clearly differentiates from sibling tools like query_memory (retrieval) and forget_memory (deletion), and the RDF format is explicitly stated.

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 extensive when-to-use guidance through anti-hallucination rules: only add facts explicitly stated by the user, ask for clarification if unsure, and never add based on assumptions. It also instructs checking get_pending_verifications() after adding. However, it doesn't explicitly contrast with alternative tools (e.g., 'use search_entity for retrieval'), though the sibling names make that reasonably clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/MauriceIsrael/SmartMemory'

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