Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
ECG_DEBUGNoWrite server diagnostics to stderr.0
ECG_DB_PATHNoSQLite file. `.eng_graph/` is used when that directory already exists and `.convo/` does not..convo/memory.db
ECG_AUTO_INJECTNo`chat` returns fact bodies. `preview` returns titles.chat
ECG_EMBEDDING_PROVIDERNo`testing`, `sentence-transformers`, or `openai-transformers`testing
ECG_AUTO_INJECT_MAX_TOKENSNoAbove this, a recall degrades to titles and says why.2500

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
ecg_get_sessionA

Start or resume the engineering-memory session for a project path.

Returns session id, repository id, stats, a short repo map, consent state, and separate database and embeddings status objects. If one of those is degraded the other is still reported. This call does not store facts. Pass the project root (or any file inside it), not a login secret.

ecg_prepare_placementsA

Score candidate facts against the repo and stage a proposal. Does not store.

Each candidate needs title and may include body, fact_type, entities (name, entity_type), confidence (0..1), and action (new, update, create, merge, replace, drop, supersede). Unknown fact and entity types are accepted.

The result is a prep_id (also returned as exchange_id) plus a classification for each candidate: likely_duplicate, possible_supersede, related, or new, with the matched fact titles and scores. The proposal lives only in process memory. Abandoning it leaves no database row.

ecg_commit_placementsA

Stage the agent's chosen placement actions. Does not write durable memory.

exchange_id is the prep_id from ecg_prepare_placements. Use this to record merge, replace, or drop decisions before the user approves ecg_commit_step. Dropped placements must not be sent on later as if they were approved.

ecg_record_provenanceA

Stage conversation turns that explain a proposal. Does not write durable memory.

Each message is {"role": "user"|"assistant", "content": "..."}. Full text is stored only if a later ecg_commit_step succeeds under consent.

ecg_approve_consentA

Record the user's consent decision. This call is the consent checkpoint.

grant is one of approve_run, approve_session, reject, or reject_session. The value must be the user's choice from the approval dialog. Do not send approve_run or approve_session on your own.

approve_run authorizes exactly one successful commit. approve_session authorizes storage for the rest of this session. reject is an audit entry and never authorizes storage. reject_session turns storage off and stops further consent prompts. Any other string is recorded and does not authorize storage.

ecg_commit_stepA

Store approved facts for one exchange. This call is the storage checkpoint.

The arguments are shown to the user in the native approval dialog. Pass the real title and body of every fact. Do not substitute "see above", a hash, or an empty placements list to hide what will be saved.

exchange_id is the prep_id from prepare, or a new id when committing placements directly. messages are provenance turns. Each placement uses the same fields as a candidate, plus action and optional supersede_existing_fact_id / target_fact_id.

Storage is refused unless the session has approve_session or an unconsumed approve_run grant. One successful commit consumes one approve_run grant. A failed commit does not consume it. An explicit supersede at confidence >= 0.75 marks the old fact superseded and links supersedes. Lower confidence, or an ambiguous target, keeps both facts and opens a conflict instead of overwriting anything.

ecg_cancel_stepB

Drop a staged proposal. No-op if it is already gone. Does not delete stored facts.

ecg_search_contextA

Return the smallest fact neighborhood for query. This is the only body export.

The server ranks facts itself from query and entity_names. It does not accept a fact-id list, so a caller cannot widen an approval by naming extra facts. Results are connected clusters labeled by their shared entity (or the top fact title). When the rendered block would exceed ECG_AUTO_INJECT_MAX_TOKENS, or ECG_AUTO_INJECT=preview, the block contains titles only and says why.

ecg_discard_proposalB

The user declined the staged proposal. Drop it. Do not store it later.

ecg_list_conflictsA

List open supersession or contradiction conflicts. Titles and ids only, no bodies.

ecg_resolve_conflictA

Resolve open conflicts. This call is the user's choice, not a silent overwrite.

resolution is new (keep the new fact, supersede the old), old or existing (keep the old fact, supersede the new), or both (keep both active). History is kept: the loser is marked superseded and linked, never deleted. conflicts is a list of conflict ids from ecg_list_conflicts.

ecg_statsB

Read-only counts for the session's repository.

Reports exchanges, active facts, superseded facts, total facts, edges, entities, and open conflicts. Fact bodies are not included.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.8/5.0

Scored across 12 tools

Disambiguation4/5

Tools divide into distinct workflow stages (session start, prepare, commit placements, commit step, search, conflicts), and descriptions explicitly clarify which call stores versus stages data. Some overlap exists between ecg_commit_placements and ecg_commit_step, and between ecg_cancel_step/ecg_discard_proposal, which could confuse ordering, but the descriptions distinguish them.

Naming Consistency4/5

All tools use a consistent ecg_ prefix followed by verb_noun snake_case (ecg_prepare_placements, ecg_commit_step, etc.). A few names like ecg_stats and ecg_search_context are noun/short forms, but the convention is otherwise predictable.

Tool Count5/5

12 tools is well within a healthy range and each maps to a distinct step in the memory workflow. The set is neither thin nor bloated for the stated purpose.

Completeness5/5

The surface covers the full lifecycle: session init, preparation, staging, provenance, consent, commit, cancellation, search, conflict listing/resolution, and stats. No obvious CRUD or lifecycle gaps remain.

Maintenance

ActivityMaintained
ResponsivenessNo issues