Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
CONTEXTFORGE_TOOLSNo`lean` (default) exposes 15 tools — the 14 core ones plus the `cf_tools` gateway to the other 55. `full` exposes all 69, as versions before 0.11.0 did.lean
CONTEXTFORGE_API_KEYYesYour API key from the ContextForge dashboard (starts with `cf_`).
CONTEXTFORGE_API_URLNoAPI endpoint. Defaults to production.
CONTEXTFORGE_DEFAULT_SPACENoDefault space for operations.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

ContextForge is this project's persistent memory. Its tools store and recall the user's projects, decisions, tasks, and past conversations across sessions — treat them as the source of truth for anything about the user's history, over local files.

Use them proactively:

  • At the START of a conversation, before answering the first question about the user's project, call memory_query (and tasks_what_next if they ask what to work on) to load what you already know. Do NOT claim you have no memory without calling it first.

  • Whenever the user references past context — "what did we decide", "where did we leave off", "yesterday", "remember", "we discussed" — call memory_query FIRST, then answer using those results.

  • Save to ContextForge with memory_ingest PROACTIVELY — whenever a decision, preference, or notable project fact emerges, not only when the user explicitly says "remember".

  • Organize saves by topic: before saving, check existing spaces via cf_tools (query "list spaces") and put the item in the best-matching space. Create a NEW space via cf_tools (query "create space") only for a clearly new MAJOR area that none of the existing spaces cover — prefer broad, folder-like areas (e.g. API, Frontend, Infra, Bugs, Decisions), NOT narrow sub-topics. When unsure, use the closest existing space rather than create a new one.

If any built-in or file-based memory is also available, ContextForge is the source of truth: read from it and WRITE to it here, not to local files.

Only if a query returns nothing should you say the memory is empty.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
memory_ingestA

Save important context to persistent memory — be proactive. Call this WHENEVER you learn information that would be valuable in a future conversation: project decisions ('we chose Postgres because X'), architectural choices, user preferences, debugging insights, recurring patterns, deadlines, stakeholder context, or any 'remember this' / 'save this' / 'note that' style request from the user. Heuristic: if you would be sad to lose this fact when the conversation ends, ingest it. Better to over-save than to under-save — the memory_query semantic search will surface what's relevant later. Always pass meaningful title and tags so the item is discoverable. Set deduplicate:false to save even if identical content already exists. ROUTE BY TOPIC: pass space:"<name>" matching the memory's topic so it lands in the right space instead of the catch-all default. If you don't yet know the project's spaces, call cf_tools with query "list spaces" once and reuse the result. Saving without space: piles everything into one default space — avoid it in multi-space projects.

memory_queryA

Search persistent memory BEFORE answering any project-specific question. You MUST call this tool: (a) at the start of any conversation that touches the user's codebase, work, or decisions, BEFORE generating any response; (b) whenever the user references prior context ('did we', 'we decided', 'remember', 'what did I save', 'last time'); (c) before making architectural or design recommendations — the user's prior decisions live here. Returns semantically relevant stored content. Skipping this when relevant context exists makes you appear to have amnesia and is the #1 reason users abandon persistent memory — always check first, even if you think you remember.

memory_list_itemsA

List all items stored in memory. Shows titles, previews, tags, and creation dates.

memory_helpA

Show help and usage instructions for ContextForge memory commands

memory_link_projectA

Link the current directory to a ContextForge project. When linked, all queries will be automatically filtered to only search within that project's spaces. This creates a .contextforge file in the current directory.

memory_current_projectA

Check the linked project at the start of every new conversation in a directory. Call this FIRST (alongside memory_query) before answering questions about the user's project, code, or work — it tells you which ContextForge project and spaces are scoped to the current working directory. If linked: false, surface that to the user and suggest memory_link_project. Pair this with memory_query as your two startup-context calls — they are the cheapest possible way to avoid hallucinating about the user's project.

memory_check_freshnessA

Check whether memories linked to git-tracked code (via related_paths on memory_ingest) are stale because the underlying code changed since they were saved. Compares each candidate's saved commit SHA against the current HEAD with a local git diff — no data leaves your machine for the diff itself. Returns up to 3 memories whose related files changed, so you can review and refresh them. Call this periodically or when you suspect saved context might be out of date.

memory_confirmA

Confirm that a memory flagged by memory_check_freshness is still accurate, even though its related code changed. Updates the memory's confirmed timestamp so it won't be flagged again until the code changes further.

memory_correctA

Update a memory flagged by memory_check_freshness with corrected content after its related code changed. Replaces the stored content and refreshes the git context (current commit SHA) so future freshness checks compare against the new baseline. For a general edit to any memory that is NOT part of a freshness check, use memory_update instead.

memory_forgetA

Delete a memory flagged by memory_check_freshness that is no longer relevant or accurate. Use this instead of memory_delete when acting directly on a freshness check result.

tasks_listA

Call this at the start of any conversation about work, planning, or status — and any time the user asks about pending/open/in-progress tasks. Shows pending tasks by default (sort by due date, urgent first). Use status "all" for everything, "resolved" for completed, "in_progress" for active work. IMPORTANT: Every task includes a dashboard URL (🔗). You MUST include these clickable links when presenting tasks to the user. If you see overdue tasks (past due date), surface them at the top of your response.

tasks_what_nextA

Call this whenever the user asks what they should work on, what's next, what's pending, or how to start the day. Trigger phrases include: 'what should I do', 'where do I start', 'qué hago hoy', 'next task', 'I have time, what's open'. Returns the highest-priority unresolved task assigned to the user, with due date and priority. Always include the dashboard URL (🔗) in your reply so the user can click through. Prefer this over generic answers when the user seems unsure about priorities — it gives a concrete next action.

session_updateA

Declare or update what THIS Claude Code session is currently working on (live presence). Call it when you start or switch tasks so parallel sessions can avoid stepping on your work. Example focus: 'working on the auth module'.

session_listA

List OTHER live Claude Code sessions working on the same project right now, and what each is focused on. By default it is scoped to THIS session's project (the one linked in the current directory) — that's where work actually collides. If the current directory isn't linked to a project, it falls back to the whole organization. Use it at conversation start and before big changes to avoid stepping on parallel sessions. Pass a specific project to scope elsewhere, or all_projects: true to see every session across the organization. Sessions expire automatically ~10 minutes after their last heartbeat.

cf_toolsA

Discover and run 55 additional ContextForge capabilities that are not in your tool list: git sync and history, spaces, projects, skills, routines, snapshots, import/export, task editing, and collaboration. If you cannot find a ContextForge capability in your tool list, search for it HERE before concluding it does not exist. Two modes: pass query with a plain-language description to search (returns full, ready-to-call schemas of the best matches), or pass name plus args to run one.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 15 tools

Disambiguation4/5

Most tools have crisp, distinct purposes (ingest vs query vs list_items, link_project vs current_project, session_update vs session_list), and the confirm/correct/forget trio is explicitly scoped to freshness-check results. The main overlaps are tasks_list vs tasks_what_next (both surface pending tasks) and the catch-all cf_tools, which makes agents uncertain whether a capability lives in the visible list or behind the gateway.

Naming Consistency4/5

A clear namespace_prefix_verb_noun convention runs through memory_*, tasks_*, and session_* (memory_list_items, memory_check_freshness, tasks_list, session_update). Deviations are minor: cf_tools breaks the namespaced verb pattern entirely, and a few names are noun-only or state-like (memory_current_project, memory_help).

Tool Count4/5

15 top-level tools sit at the top of the comfortable range and each maps to a real workflow (memory lifecycle, tasks, sessions, project scoping). The count is kept sane by pushing 55 capabilities behind cf_tools, though memory_confirm/correct/forget could plausibly collapse into one parameterized tool.

Completeness3/5

The memory surface covers list/create/search/delete, but general update and delete are absent from the visible list — descriptions reference memory_update and memory_delete as if they were callable, which is a dead end agents will hit. Task creation/completion and session teardown are also missing, forcing agents through cf_tools for routine CRUD.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues