Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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:

  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.

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:

  • You can make SOFT deductions based on language understanding (e.g., 'knows → probably acquaintances')

  • BUT you MUST distinguish between YOUR deductions and FORMALLY PROVEN facts

  • Use this tool to CHECK if your soft reasoning is formally proven

  • If not proven, use verify_inference() to confirm, then suggest_rule() to formalize

When to use:

  • To verify if a fact exists in the graph

  • To check what the system KNOWS FOR CERTAIN (not what you deduce)

  • To explore relationships and connections

Query Guidelines:

  • ALWAYS scope queries to user namespace with ':' prefix (e.g., ':User', ':Alice')

  • Use LIMIT to avoid overwhelming results (max 1000 auto-injected)

  • Common predicates: foaf:knows, schema:worksFor, schema:colleague, rdf:type

Example workflow 1 (Simple check):

  1. User: 'Is Alice my friend?'

  2. You think: 'Hmm, I see :User foaf:knows :Alice, so maybe friends?'

  3. You call: verify_inference(':User', 'foaf:friend', ':Alice')

  4. Result: 'Not formally proven'

  5. You tell user: 'You know Alice, but friendship is not formally established. Should I create a rule?'

Example workflow 2 (Proactive rule learning):

  1. User asks: 'Can Gilles vote?'

  2. You query: ASK { :Gilles :canVote ?x } → False

  3. You think: 'Voting requires age ≥ 18. Do I know Gilles' age? No.'

  4. You query: ASK { :Gilles :hasDrivingLicense ?x } → True

  5. YOU IMMEDIATELY CALL: suggest_rule( rule_id='driving_license_implies_adult', description='Having a driving license implies being an adult (≥18)', sparql_pattern='CONSTRUCT { ?person :isAdult true } WHERE { ?person :hasDrivingLicense ?license }' )

  6. After user approves, you can then infer :Gilles :isAdult true → can vote

Output format:

  • SELECT: Returns table of results as list of dicts

  • ASK: Returns boolean (True/False)

  • CONSTRUCT/DESCRIBE: Returns graph triples

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:

  1. User asks: 'Is Alice my friend?'

  2. You check: query_memory('ASK { :User foaf:knows :Alice }')

  3. Result: True (they know each other)

  4. Your soft reasoning: 'knows → maybe friends?'

  5. YOU MUST CALL: verify_inference(':User', ':isFriendOf', ':Alice')

  6. Result: 'Not proven'

  7. You respond: 'You know Alice, but friendship isn't formally established.'

  8. If user confirms: Call suggest_rule() to formalize

Returns:

  • If proven: Source (user/rule), confidence, explanation, rule name

  • If not proven: Suggestion to either add explicitly or create rule

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:

  1. EXPLAIN & ASK: You MUST explain the rule and ask for explicit permission FIRST.

    • En Français: "Puis-je ajouter cette règle d'inférence ?"

    • In English: "May I add this inference rule?"

  2. WAIT: Do NOT call suggest_rule until the user says YES.

  3. SUGGEST: Only after approval, call this tool.

  4. CONFIRM: The user must then approve the pending rule using approve_rule (which you CANNOT call yourself).


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:

  1. You: 'Voting implies age >= 18. Shall I formalize this?'

  2. User: 'Yes'

  3. YOU CALL: suggest_rule(...)

  4. System: Previews inferences, adds to pending approval

  5. STOP: You wait for user to review.

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:

  • Use descriptive rule_id (snake_case)

  • SPARQL must be CONSTRUCT query

  • Set confidence < 1.0 for uncertain rules

  • Preview shows what WOULD be inferred

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 suggest_rule, wait for the user to read it, and only call this if they strictly say 'Approved' or 'Yes'.

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:

  • Load a file: load_document(file_path='/path/to/rules.pdf')

  • Upload content: load_document(content='Rule 1:...', title='My Rules')

What it does:

  1. Parses the document

  2. Stores metadata in the graph

  3. Analyzes content with LLM to extract business rules

  4. Saves extracted rules as 'PENDING' for validation

Options:

  • store_content: Set to True to save full text in graph

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:

  1. The triple is removed from the graph

  2. Its provenance reification nodes (source, timestamp, confidence) are also removed

  3. Facts inferred FROM this fact are NOT automatically removed → Use query_memory to check if dependent facts exist before forgetting

Format: ':Subject predicate :Object'

Examples: forget_memory(':User foaf:knows :Alice') forget_memory(':Bob schema:worksFor :AcmeCorp')

Prompts

Interactive templates invoked by user choice

NameDescription
remember-factStore a new fact or piece of information in semantic memory
query-knowledgeSearch for information in semantic memory
add-custom-ruleCreate a custom inference rule to automatically derive new knowledge
show-statsShow statistics about the knowledge graph (how much is known, inference activity, etc.)
verify-inferencesReview and confirm/reject uncertain inferences that need user verification

Resources

Contextual data attached and managed by the client

NameDescription

No resources

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