contextforge-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CONTEXTFORGE_API_KEY | Yes | Your API key from the dashboard | |
| CONTEXTFORGE_API_URL | No | API endpoint (defaults to production) | https://api.contextforge.dev |
| CONTEXTFORGE_DEFAULT_SPACE | No | Default 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
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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 |
| 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 |
| 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 |
| 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 |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
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.
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.
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.
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.