Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
CONTEXTFORGE_API_KEYYesYour API key from the dashboard
CONTEXTFORGE_API_URLNoAPI endpoint (defaults to production)https://api.contextforge.dev
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.

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
{}

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_helpA

Show help and usage instructions for ContextForge memory commands

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_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 59 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

A4.3/5.0

Scored across 11 tools

Disambiguation4/5

Most tools have clear, distinct roles: memory ingest/query/freshness tools, task list/next tools, session list, and the catch-all cf_tools. There is mild overlap between tasks_list and tasks_what_next, and cf_tools can serve as an alternate entry point for capabilities, but the descriptions provide strong usage triggers.

Naming Consistency4/5

The tools mostly follow a clear prefix-plus-verb pattern like memory_ingest, memory_query, tasks_list, and session_list. The main inconsistency is cf_tools, which breaks the naming convention, and memory_help/tasks_what_next are slightly less verb-oriented, but the overall pattern is still readable.

Tool Count5/5

With 11 primary tools, the visible surface is well-scoped and within the ideal range for an MCP server. The cf_tools meta-tool cleverly keeps the count manageable while exposing 59 additional capabilities, so the apparent tool count matches the server's core workflows.

Completeness4/5

The memory lifecycle is well covered with ingest, query, freshness checking, confirm, correct, and forget, and task/session reading is present. General memory updates/deletes and task editing are not first-class tools but are accessible through cf_tools, which creates a minor discoverability gap rather than a true dead end.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive