ContextForge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| UV_SYSTEM_CERTS | No | Set to '1' to use system certificates when behind an SSL-inspecting proxy. May be needed for uv commands and server startup. | |
| CONTEXTFORGE_HOME | No | Override the base directory for all ContextForge data. Defaults to ~/.contextforge. | |
| CONTEXTFORGE_LOG_FILE | No | Full path to an additional log file. Alternative to CONTEXTFORGE_DEV_LOG_DIR. | |
| CONTEXTFORGE_LOG_LEVEL | No | Log level for the server. Default is INFO; set to DEBUG for full FTS scoring breakdowns. | |
| CONTEXTFORGE_DEV_LOG_DIR | No | Directory for an additional log file (for development/dogfooding). The normal log in ~/.contextforge/logs/ is always written. |
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 | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_componentA | Create a new Component entity. A Component is any coherent unit of functionality that you hold context
about: an internal subsystem, an external service, an API, a database,
a library, or a tool. The |
| create_repoA | Create a new Repo entity. Repos hold long-lived facts about a codebase: style, testing, layout, local-dev setup, conventions. A repo optionally belongs to a parent Component (e.g. gateway-proxy-repo -> component:api-gateway). |
| create_taskB | Create a new Task entity. Tasks are transient units of work (a feature, a bug, an investigation) that compose context by linking specific Component/Repo/Governance refs via link_task. Scaffolded subtopics: goal, plan, notes. |
| create_governanceA | Create a new Governance entity — a reusable guideline. Governance entities hold cross-cutting rules that apply to multiple
components/repos/tasks: security policies, API design standards,
branding guidelines, user preferences. Any other entity can reference
them via When assembling a task pack, governance refs cascade: the task's own governance + governance attached to each linked component/repo + parent components of linked repos. All deduped. Scaffolded subtopics: overview, rules. |
| list_componentsB | List all Components, optionally filtered by kind. |
| list_reposB | List all Repos. |
| list_tasksB | List all Tasks. |
| list_governance_entitiesC | List all Governance entities. |
| delete_entityA | Delete an entity and ALL its subtopics. Destructive. Also cleans up: aliases, task_links referencing this entity, governance links, uses-graph edges, and nullifies repo->component parent pointers. Requires an entity-level ref (no subtopic). |
| add_aliasA | Add a short nickname for an entity. Globally unique. Example: add_alias("component:api-gateway", "gw") — then resolve_ref("gw") returns the component. |
| remove_aliasC | Remove an alias from an entity. |
| resolve_refA | Resolve a fuzzy query ("the gateway", "gw", "auth-gw") to candidate refs. Checks exact slug, exact alias, and case-insensitive name substring. Returns ranked candidates [{ref, source, score}] — call this before writing if the user refers to something by nickname or description. |
| get_contextA | Read the current context for an entity or a single subtopic. Accepts an entity ref ("component:api-gateway") or a subtopic ref ("component:api-gateway/auth"). For entity refs, returns the meta + all subtopics. |
| upsert_contextB | Create or overwrite a subtopic's full content. Requires a subtopic ref. Parent entity must already exist. Clears any previously stored source_url/source_name when content is overwritten without source metadata. |
| append_contextB | Append content to a subtopic, creating it if missing. Separates appended content from existing with a blank line. |
| delete_contextC | Delete a single subtopic. Parent entity is preserved. |
| import_contentA | Store content fetched from an external source as a subtopic. Use this after another MCP tool (e.g. an Atlassian MCP for Confluence)
returns page content — ContextForge then owns it as a snapshot with
source tracking. |
| refresh_sourceA | Return the source_url for a subtopic so the caller can re-fetch. ContextForge does NOT fetch. The caller (LLM) uses another MCP tool or HTTP fetcher to retrieve fresh content, then calls import_content again with the same ref. |
| list_stale_sourcesC | List imported subtopics whose source_fetched_at is older than a cutoff. |
| link_taskB | Wire refs (component/repo/governance, optionally with subtopic) into a task. Subtopic-level refs keep packs focused. Governance refs attached here also cascade to the assembled pack; governance attached to linked components/repos cascades automatically too. |
| unlink_taskB | Remove refs from a task's link list. Idempotent. |
| get_task_packA | Assemble the full context pack for a task. Returns the task's own meta+subtopics, all resolved linked refs, and a
deduplicated governance section. If include_always is True (default),
refs from config.json When focus is True (default), entity-level refs with more than
per_entity_top_k subtopics are FTS-narrowed against the task's
description + own notes — only the top-K most relevant subtopics are
included; the rest are returned in |
| suggest_task_linksA | Propose candidate refs to link into a task. Walks the |
| add_governanceA | Attach a governance ref to a component/repo/task. The governance content will be included in any task pack that touches this entity (directly via link_task, or via parent-component cascade for repos). Cannot attach governance to another governance entity. |
| remove_governanceC | Detach a governance ref from an entity. |
| add_external_refA | Attach a reference to an external tracking system (Jira, GitHub, etc.). ContextForge does not fetch these — it just stores pointers. Use a separate MCP server (Atlassian, GitHub, etc.) to retrieve current state. |
| remove_external_refC | Detach an external reference from a task. |
| searchC | Full-text search (SQLite FTS5) across all subtopic content. |
| get_configA | Return the current ContextForge config (always_include, workspaces). |
| add_always_includeA | Add a ref to the always_include list. Any ref in this list is automatically included in every task pack. Typical use: a personal-prefs governance entity you want everywhere. |
| remove_always_includeC | Remove a ref from the always_include list. |
| bind_workspaceA | Associate a local workspace path with a repo slug. Once bound, get_current_workspace(path) returns the repo slug so the LLM can auto-select relevant context when you're working in that dir. The MCP client's Roots capability is the canonical source of the current workspace path; this tool expects that path passed in. |
| unbind_workspaceB | Remove a workspace→repo binding. |
| get_current_workspaceB | Resolve a workspace path to its bound repo (and parent component, if any). |
| reindexA | Rebuild the SQLite + FTS5 index from markdown files on disk. Use after manual edits on disk, or if the index seems stale. Filesystem is the source of truth. |
| tail_logsA | Return the most recent lines from the persistent usage/debug log. The log at ~/.contextforge/logs/contextforge.log (rotating) captures tool invocations, pack assemblies (with dropped counts, sizes, timings), entity creates, links, governance attachments, resolves, suggestions, context writes, and workspace binds. This is the primary signal for understanding real usage and tuning focus/governance behavior. |
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 36 tools
Pairings like append_context/upsert_context/import_content and get_context/get_task_pack are superficially similar, but their descriptions clearly delineate write mode (append vs. overwrite vs. imported snapshot) and read scope (single entity vs. assembled pack). The create_governance/add_governance and delete_context/delete_entity pairs are likewise disambiguated by entity-level vs. ref-level wording. No two tools appear to do the same thing.
Every tool follows a lowercase snake_case verb-first pattern (append_context, list_repos, bind_workspace, unlink_task), and paired operations share prefixes (add_*/remove_*, create_*, list_*). 'search' and 'reindex' are bare verbs but still read as imperatives and don't clash with the pattern. This is a highly internally consistent naming scheme.
36 tools is heavy, but the domain is genuinely broad: four entity types, subtopic writes, linking, aliases, external refs, workspace bindings, imports, config, search, and logging each get explicit surface area. Some thin pairs like add/remove_always_include and bind/unbind_workspace could be folded into a config/workspace update tool, and agents face a large decision space. The count is defensible but sits above the well-scoped band.
CRUD is nearly complete: create/list/delete for entities, full read/write/delete for subtopics, link/unlink, add/remove for aliases, refs, and governance, plus a coherent re-fetch workflow via refresh_source + import_content. Notable gaps are the absence of entity metadata updates (re-parenting a repo or editing a task's description requires delete+recreate) and no listing of aliases or external refs per entity. get_task_pack, search, and suggest_task_links cover the high-level workflows well.