ccontext
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CCONTEXT_ROOT | No | The path to your project directory where the context/ folder will be created. If not set, uses the current working directory. |
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": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_contextA | Read this first or risk repeating work and missing critical decisions. Your execution memory that persists across sessions. Contains: vision (goal), sketch (static blueprint), milestones (phases), tasks (deliverables), notes (lessons), and references (key files). Other agents update this too - check regularly. Returns 'version' for change detection, 'now' for active status, 'diagnostics' (debt score + top issues), and may include 'warnings'/'hints' for suggested actions. |
| commit_updatesA | Apply multiple updates in ONE call (reduces friction; keeps context current). Input: ops=[{op: ...}, ...] and optional dry_run=true. Supported ops:
|
| update_visionA | Set or update the project vision - what we're building. This is a short, fixed statement that captures the project goal. Example: 'Build secure SaaS platform for 10K users' |
| update_sketchA | Update the execution blueprint (markdown). Sketch is static: architecture, strategy, constraints, major decisions. Do NOT put TODOs, daily progress, task lists, or milestone status here (use tasks/milestones instead). Recommended sections: ## Architecture, ## Strategy, ## Risks, ## Decisions. Update on: architecture/strategy shifts or major risk changes. |
| get_presenceA | Get all agents' current status - what they're doing/thinking. Essential for multi-agent coordination. Each agent has: ID, status (natural language), last update time. |
| update_my_statusA | Tell other agents what you're doing - they can't see your work otherwise. 1-2 sentences describing your current focus, intent, or blockers. Example: 'Debugging JWT edge case, found timezone issue' or 'Blocked on schema confirmation'. |
| clear_statusA | Clear your presence status (remove stale/finished status). Use this when you’re done or after a handoff so old statuses don’t linger and mislead. |
| create_milestoneA | Start a new coarse project phase (timeline). Use for 2–6 big stages (e.g., 'Phase 1: Core Implementation'). Exactly one milestone should be active at a time. |
| update_milestoneA | Modify milestone details or advance status (pending→active→done). Use to mark phase transitions or adjust phase scope/outcomes. |
| complete_milestoneA | Close a milestone and record what was accomplished. Outcomes become permanent project history visible to future sessions. |
| remove_milestoneA | Delete a cancelled or mistaken milestone. Completed milestones should be kept as project history. |
| list_tasksA | Find tasks by status (planned/active/done) or assignee. Use to see what work exists and check progress across sessions. |
| create_taskA | Create a deliverable work item with 3–7 steps. Use for concrete outcomes that span handoffs or need tracking. Prefer linking it to a milestone via milestone_id. |
| update_taskB | Update task execution state - status/steps/details (and optional milestone link). Keeps progress accurate for handoffs and resumption. |
| delete_taskA | Remove a cancelled or mistaken task. Completed tasks auto-archive after 7 days - no need to delete them. |
| add_noteA | Preserve important knowledge for future sessions - lessons, warnings, decisions. TTL decays and auto-archives over time. Recommended tiers: 10=short-term, 30=normal, 100=long-term. Example: 'API rate limit is 100/min - batch requests to avoid throttling' |
| update_noteA | Refresh a note's ttl to prevent decay, or update its content. Use when a note is still valuable but its ttl is getting low. |
| remove_noteA | Delete an obsolete note immediately. Prefer letting low-value notes decay naturally via ttl lifecycle. |
| add_referenceA | Bookmark important file paths or URLs for quick navigation. TTL decays over time. Recommended tiers: 10=short-term, 30=normal, 100=long-term. Use for: key source files, API docs, configs. Example: 'src/core/auth.py - OAuth implementation' |
| update_referenceA | Refresh a reference's ttl to prevent decay, or update its details. Use when a reference is still valuable but its ttl is getting low. |
| remove_referenceA | Delete an obsolete reference immediately. Prefer letting outdated references decay naturally via ttl lifecycle. |
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 21 tools
Each tool targets a distinct entity and action: tasks, milestones, notes, references, presence, and context. The batch tool commit_updates is clearly distinguished as a multi-op alternative to the single-purpose tools, reducing ambiguity.
All tools follow a consistent verb_noun pattern in snake_case (e.g., list_tasks, create_milestone, add_note, remove_reference). Minor verb variations (add vs create, remove vs delete) correspond to natural language for each entity but maintain the same structure.
21 tools is on the higher end but appropriate for the broad scope of project context management (context, tasks, milestones, presence, notes, references). Each tool serves a distinct purpose, though some could theoretically be folded into commit_updates.
The tool surface covers the full lifecycle of each core domain entity: CRUD for tasks, milestones, notes, and references; presence management; and vision/sketch updates. The batch commit_updates fills any gaps for atomic multi-entity updates, and get_context provides a comprehensive view for resuming work.