Context Mode vs Keelen
A side-by-side look at the Context Mode and Keelen MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Context Mode for coding agents work as a local process; choose Keelen for coding agents over a hosted endpoint. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Context Mode when
- You need dedicated capabilities in the Coding Agents domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You want tools like
ctx_batch_execute, ctx_execute, ctx_execute_file.
Choose Keelen when
- You need dedicated capabilities in the Coding Agents domain.
- You prefer a remote HTTP/SSE transport.
- You want tools like
list_projects, create_project, submit_request.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Coding Agents | Coding Agents |
| Quality signal | 69/100 · Great | 57/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Remote HTTP/SSE |
| Auth | No auth required | Not declared |
| Pricing | Free | BYOK (pay the provider) |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 32,137 | 0 |
| Directory activity | 3 views 0 installs 0 upvotes | 0 views 0 installs 0 upvotes |
| Tools | 10 | 49 |
| Full listing | View Context Mode | View Keelen |
Tools & capabilities
Context Mode tools 10
ctx_batch_executeRun multiple commands + search multiple queries in ONE call. Opt-in `concurrency: 1-8` for I/O-bound batches.ctx_executeRun code in 12 languages. Only stdout enters context.ctx_execute_fileProcess files in sandbox. Raw content never leaves.ctx_indexChunk markdown into FTS5 with BM25 ranking.ctx_searchQuery indexed content with multiple queries in one call.ctx_fetch_and_indexFetch URL, chunk and index. Cache reuses content within TTL (default 24h, override per-call with `ttl: <ms>`). `ttl: 0` or `force: true` to bypass. Pass `requests: [{url, source}, ...]` + `concurrency: 1-8` for parallel multi-URL.ctx_statsShow context savings, call counts, and session statistics.ctx_doctorDiagnose installation: runtimes, hooks, FTS5, versions.ctx_upgradeUpgrade to latest version from GitHub, rebuild, reconfigure hooks.ctx_purgePermanently deletes all indexed content from the knowledge base.
Keelen tools 49
list_projectsList the projects in this workspace, with what each one is building.create_projectStart building something new: creates a GitHub repo and begins work on it. For a NEW repo. Given an existing repo, import_project(repo_full_name) is the right call — this one would create a second, empty repo beside it (list_github_repos() browses what the workspace can see). Scaffolds a new GitHub repo, a bootstrap-mode project, and submits `build_description` as the project's first Roadmap Request. `name` is a concise GitHub short repo slug (no owner); `project_kind` is REQUIRED and one of library | node_library | python_library | service | cli | web_app | godot_game | roblox_game; `preview_command` is required iff `project_kind == 'web_app'`. `engine` is OPTIONAL — one of claude_code | codex | glm | kimi | grok (defaults to claude_code); codex, glm, kimi, and grok require the workspace to have a matching connected credential. `org` is OPTIONAL — a GitHub organization login to create the repo inside (e.g. your company org); omit it to land the repo on a member's personal account. `private` defaults to True. `ci_runs_on` is OPTIONAL — the CI runner labels for the scaffolded workflow, e.g. ["self-hosted", "linux", "x64", "my-fleet"]. Omit it to inherit the workspace default (ubuntu-latest if unset). Labels no registered org runner carries are rejected, because GitHub would queue such a job forever rather than fail it. `framework` is OPTIONAL and `web_app`-only — one of vite | next (defaults to vite). It picks the scaffolded frontend rails: `vite` a vanilla-TypeScript SPA, `next` a Next.js app-router app. Passing it with any other `project_kind` is an error. The repo is created on the GitHub account of a workspace member with repo-create OAuth access (this path has no specific caller user), so the returned `repo` owner is whichever member's token resolved (or the chosen `org`). If no member has repo-create access — or the resolving member can't create in `org` — the call returns an actionable error. Returns {project_id, repo, thread_id, next_action, poll_after_seconds, next_step}; next_step names the follow-up poll of get_request_status with the returned thread_id. On the rare arm where the first Request failed to submit, next_action is "call_tool" with next_tool="submit_request". If scaffolding fails after the repository has been created, best-effort compensation deletes that just-created repository so a retry can reuse the name — this tool can therefore remove external state it created moments earlier.submit_requestAsk for a change in plain English: a feature, a bug fix, or a new direction. Each call carries ONE feature or intent; a multi-feature ask belongs in separate requests. `text` must be under 16000 characters. Returns {thread_id, status, next_action, poll_after_seconds, next_step}; next_step names the re-check of get_request_status after poll_after_seconds.get_request_statusCheck what happened to a request, and read any questions it asked back. Intake is async (~5min cadence), so the status changes between calls. `next_action` is one of: "wait" (still processing), "answer_questions" (answer_request takes one answer per question), "done" (see generated_roadmap_item_ids), "cancelled" (terminal, no items), "failed" (see intake_failure_reason), "approve_plan" (a planned request's plan awaits the user's approval in the dashboard). A planned request also carries `stage`, `plan_cycle` and `max_cycles`.set_product_visionSay what this product is for, so every run knows what it is building toward. `vision_md` is free-form markdown and must be non-empty. Tenant-scoped: a project not in the caller's workspace 404s. Returns {project_id, product_vision_md, updated_at, next_step}.set_product_goalSet the outcome to aim at right now, so work is prioritised toward one thing. `goal_md` is free-form markdown and must be non-empty. Tenant-scoped: a project not in the caller's workspace 404s. Returns {project_id, product_goal_md, updated_at, next_step}.list_roadmapSee what is planned for a project and in what order. Queued rows also say whether the expand picker would elect them (`electable`) and, when not, why it skips them (`skip_reason`: awaiting_intake_thread | awaiting_clarification | crash_capped | noop_capped | crash_cooldown | noop_cooldown | held_on_open_pr | other). The first reason that applies, in that order, is the one returned. `awaiting_clarification` means the planner asked a planning question about the item and waits for the answer: `list_escalations` returns that card with the item's `roadmap_item_id`. A skipped item ahead of yours does not delay it.reorder_roadmapChange what gets built first. `ordered_ids` is the desired front-to-back order of queued roadmap-item ids (list_roadmap returns them). The first id becomes the highest priority — the cadence expands the lowest-priority_int queued item next. Horizon pins still dominate: a pinned-later item stays at the back and a pinned-now item at the front, regardless of position in `ordered_ids`. Ids that are unknown or no longer queued are skipped; duplicates are rejected. Returns {updated, queue, next_step}.cancel_roadmap_itemCancel / close a single roadmap item (list_roadmap returns its id). For a DELIVERED or duplicate item that keeps re-parking: once the work has shipped, every expand produces no dev-ready tasks and files a recurring `roadmap_item_parked` escalation that has to be acked. Cancelling drops the item out of the expand queue AND resolves any open expand-lane escalation for it. Business-level replay guard: an already expanded/cancelled item changes no state, and the dashboard can restore a cancelled item. Refuses (409) while the item is actively being expanded (a retry once that iteration ends succeeds). Returns {id, status, changed, next_step}.clear_horizon_pinClear a queued roadmap item's horizon pin (now/next/later → none). A horizon pin dominates the queue sort, so `reorder_roadmap` cannot move a pinned item out of its band — a stale `now` pin on a delivered/duplicate item clogs the front of the queue. This unpins it and reprices the queue so the item follows plain priority order again (and reorder_roadmap can then move it). Only queued items carry a settable pin (in-flight / shipped items derive theirs), so this refuses (422) on a non-queued item — a delivered item is closed with cancel_roadmap_item. Returns {id, previous_pin, horizon_pin, next_step}.rollback_roblox_placeRoll a Roblox project's place back to a previously-published version. For a `roblox_game` project, re-publishes the RETAINED build artifact for `version_number` (the web Roblox Publishing card lists published versions) — it never rebuilds from source, so rollback is fast + deterministic. This mints a NEW Roblox version pointing at the old build. Unknown version → 404; a version with no retained artifact → 422; a place open in Studio / rate-limited → 409 (a retry can succeed); an invalid or unscoped Open Cloud key → 409 / 403. Returns {version_number, env, published_at, status, next_step}.project_statusCheck how a project is doing: what is in flight, what shipped, what is stuck. Returns lifecycle status, open task count, queued roadmap item count, runs today, verification pass rate, open blockers, pause state, and freshness. Zero `open_tasks` does not mean an empty roadmap: `queued_roadmap_items` counts planned work awaiting expansion, including work held while the scheduler is disabled. list_roadmap returns those items. `glm_peak_paused` is NOT a fault and sets no pause columns: it is the ephemeral GLM peak-hours skip. True means clean PRs hold and runs stop until `glm_peak_resumes_at`. It is an intentional cost gate, so the accurate description is "waiting for off-peak", not a failure. For `web_app` projects the optional `ui_review` block can mint a GitHub installation token and read the default branch's `ui-review.json`, so this status call is not guaranteed to be a purely local read. `model_roles` (only when the Researcher/Integrator feature is enabled for the project) reports each optional stage's on/off configuration and last outcome.- +37 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Context Mode
{
"mcpServers": {
"context-mode": {
"command": "npx",
"args": [
"-y",
"context-mode"
]
}
}
}
Keelen
{
"mcpServers": {
"keelen": {
"url": "https://keelen.ai/mcp"
}
}
}
Frequently asked questions
Context Mode is categorized under Coding Agents and uses a local stdio subprocess. Keelen belongs to Coding Agents and uses a remote HTTP/SSE transport. Pick Context Mode for coding agents work and Keelen for coding agents.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Context Mode is listed as free. Auth: no auth required. Keelen is bring-your-own-key: usage is billed by the API provider you supply a key for. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add context-mode and keelen as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Context Mode has a quality signal of 69/100 (Great) with 3 views, 0 installs and 32,137 GitHub stars. Keelen has 57/100 (Good) with 0 views, 0 installs and 0 GitHub stars.