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
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
storeB

Store a memory.

Args:
    content: The memory content to store.
    tags: Comma-separated tags (e.g. "preference,ui,dark-mode").
    context: When/where this memory applies.
    importance: 1-10, how important this memory is.
    namespace: Namespace for organizing memories.
correctA

Store a correction. Always maximum importance. Always surfaces first.

Use this when the AI made a mistake and you want to prevent it from
happening again. Corrections override normal memories.

Args:
    content: What the correct behavior/answer should be.
    context: When/where this correction applies.
    tags: Comma-separated tags.
    namespace: Namespace for organizing memories.
recallB

Search memories by relevance. Corrections surface first.

Args:
    query: What to search for.
    limit: Max results to return.
    namespace: Filter by namespace.
checkA

Pre-flight check: see if any corrections apply before taking an action.

Call this before doing something to see if there's a stored correction
that should change your approach.

Args:
    planned_action: Describe what you're about to do.
    namespace: Filter by namespace.
helpedA

Mark whether a surfaced memory actually helped.

This feedback loop is what makes NeverOnce learn.
Helpful memories get stronger. Unhelpful ones decay.

Args:
    memory_id: The memory ID (from recall results).
    did_help: True if the memory was useful, False if not.
forgetB

Delete a memory by ID.

Args:
    memory_id: The memory to delete.
statsB

Get memory store statistics.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 7 tools

Disambiguation4/5

Most tools have clearly distinct purposes: store vs correct are differentiated by intent (general memory vs correction), and recall vs check serve different workflows (searching vs pre-flight verification). Minor ambiguity exists between store and correct since both write memories with similar arguments, but the correction semantics are explicit.

Naming Consistency4/5

Tool names are mostly single-word imperative verbs (store, correct, recall, check, forget), which is a clear and predictable pattern. Two deviations: 'helped' is past tense rather than imperative, and 'stats' is a noun rather than a verb, creating minor inconsistency.

Tool Count5/5

Seven tools is well-scoped for a memory store: write, special write, read/search, preflight check, feedback, delete, and stats. Each tool serves a distinct operational need without redundancy or bloat.

Completeness4/5

The core memory lifecycle is covered: store, search, correct, provide feedback, delete, and inspect. Minor gaps exist, such as no direct memory content editing or namespace management, but the feedback and correction mechanisms fill most practical needs.

Maintenance

ActivityInactive
ResponsivenessSyncing