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
brain_searchC

Search ASM across vault pages, mapped code, and immediate shared-memory records.

brain_nodeB

Get full details of a brain node by id (e.g. 'vault:api-agent-allowlist', 'api:src/server/routes.py').

brain_neighborsB

Neighbors of a node up to depth hops (BFS, max 50 results). Includes cross-layer links between vault knowledge and code.

brain_pathB

Shortest path between two brain nodes (BFS over all edge types).

brain_contextA

THE tool to call before touching a file: given an absolute or relative file path, returns what the brain knows — the matching node, its code neighbors, linked vault knowledge pages (gotchas/decisions about it), and recent cross-agent access events.

memory_recentA

Newest shared records from any agent, in brief form: summary, files, open threads with their ids, and a details preview. Words in query filter the records; any word may match. Open a full record with brain_node('memory:').

memory_recordA

Persist a completed unit of work into immediate ASM memory and the Obsidian daily log.

Call after changing files. summary is one line, at most 500 characters, naming what actually changed; the narrative, verification and context go in details. Record concrete outcomes and unresolved work; never include secrets, credentials, raw private transcripts, or claims that were not verified. supersedes names earlier memory ids this record replaces (a corrected fact, a thread now closed); they stop surfacing in search and recall but stay readable by id. Credentials and card numbers are redacted mechanically; redactions lists what kinds. The response lists thread_ids (<record-id>#<n>) for the open threads it stored. resolves closes what this work finished: a thread id <record-id>#<n>, a record id (all its threads), or a plan page vault:<id> (marked done). corrects files stale claims for the curator: [{"target": "vault:" | "mem:" | "idx::", "claimed": ..., "truth": ..., "evidence": [...]}]. Both are recorded in the lifecycle ledger.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 7 tools

Disambiguation4/5

The six brain_* query tools are semantically distinct (search vs. node lookup vs. neighbors vs. path vs. file context), and the two memory_* tools handle read vs. write. brain_context and brain_neighbors overlap somewhat (both pull neighbors), but descriptions clarify the intended use.

Naming Consistency5/5

All seven tools follow a strict prefix_noun/verb pattern with two clear families: brain_* (graph queries) and memory_* (shared-memory read/write). snake_case is used consistently throughout.

Tool Count5/5

Seven tools is well-scoped for an ASM/knowledge-graph memory server, covering structured query (search, node, neighbors, path, context) and memory lifecycle (recent, record) without excess.

Completeness3/5

The surface covers read-side graph exploration and memory write/read, but lacks any update/edit/delete for records (only 'supersedes'/'resolves'/'corrects' fields on write) and no explicit lifecycle-management tools. A create+read pattern without standalone mutation tools is a notable gap.

Maintenance

ActivityMaintained
ResponsivenessNo issues