All servers · Code & repositories
Keelen
io.github.jamie7893/keelen · v1.0.0
Has write/delete toolsTools changed (7 days)
Measured by MCP Station
| Last check | Reachable |
|---|---|
| Checked at | — |
| Check success 7 / 30 days | — |
| First-try success 30 days | — |
| Median response | — |
| Lookups 30 days | — |
| Authentication | No auth |
| MCP version | 2025-06-18 |
| Rank score | — |
| Declared risk | Has destructive tools (destructiveHint) |
| Capabilities declared | prompts, resources, tools |
| Tool definitions | 49 tools · with description 100% · input schema is an object 100% · read/destructive hints 100% |
Description written by the publisher, not verified
Autonomous dev team steered from chat: plain-English requests in, tested merged PRs out.
Connect
streamable-http · https://keelen.ai/mcp
claude mcp add --transport http keelen https://keelen.ai/mcp{
"mcpServers": {
"keelen": {
"url": "https://keelen.ai/mcp"
}
}
}Tools as reported by the server
list_projectsList the projects in this workspace, with what each one is building.create_projectwrite/deleteStart 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 GitHubsubmit_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 theget_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)set_product_visionwrite/deleteSay 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_goalwrite/deleteSet 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_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 tcancel_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 outclear_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 itemrollback_roblox_placewrite/deleteRoll 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 mintsproject_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`close_taskwrite/deleteClose a task that should not be built — a duplicate, or work already shipped. For a task on the board that is obsolete: the change already landed in another PR, a sibling task covers it, or the user changed direction. The task is marked `cancelled` and keeps ALL of its history (acceptance criteria,get_product_goalRead a project's current product goal (the outcome work is aimed at). The paired setter `set_product_goal` replaces the whole document rather than appending to it, so a write without a prior read silently discards whatever the user already recorded; adding a line means reading the current text, editget_product_visionRead a project's current product vision (what the product is for). The paired setter `set_product_vision` replaces the whole document rather than appending to it, so a write without a prior read silently discards whatever the user already recorded; adding a line means reading the current text, editilist_escalationsSee what the work is stuck on and waiting for a human decision about. `project_status` only COUNTS open escalations; this returns each one with its kind, reason, detail_md, recommended_action, and (when task-scoped) the blocked task's title + PR url. A card about a roadmap item carries its `roadmap_resolve_escalationwrite/deleteAcknowledge a handled ask only when no blocked task becomes invisible. `decision_md` is a required short note (why/how it was resolved), appended to the escalation's detail_md as an audit trail. Resolving a project_pause / orphan_pause RESUMES the project (clears the pause). A blocked task's final tanswer_planning_questionwrite/deleteAnswer an open planning question and release its roadmap item. Use this for a `list_escalations` row with reason `expand_needs_clarification` (its `next_tool` names this tool). The planner asked one or more product questions about one roadmap item; give ONE answer that covers every question (1-4,000retry_blocked_taskGrant one fresh attempt after fixing a recovery-budget task block. ``escalation_id`` is the task_block id returned by ``list_escalations``. Eligibility, tenant, task, failure class, task status, and competing blockers are all derived server-side. This is distinct from ``resolve_escalation``, which rrequeue_for_reviewwrite/deleteReturn one blocked task's existing pull request to normal review. Requires a personal OAuth connection of an active workspace owner; workspace keys are refused. Pass the task id (not an escalation id), the PR's exact 40-character head SHA, a reason (1-2000 characters) and a request_id you choose (1-rearm_roadmap_itemRun the dashboard's replay-guarded same-item dependency re-arm. ``escalation_id`` is an ``expand_produced_nothing`` or ``roadmap_item_parked`` escalation id. Keelen verifies delivered structural prerequisites, grants one bounded expand retry, preserves the roadmap item id and ``depends_on_item_ids``resolve_platform_policy_conflictResolve a platform-policy dead-end with a structured plan decision. Choose ``decision`` from ``reuse_existing_evidence``, ``raise_project_cap``, ``remove_scenario``, or ``correct_evidence_selector``. ``raise_project_cap`` also requires ``project_cap`` (6..32). The decision becomes a new task-plan seset_ui_review_scenario_capSet this web_app project's ui-review scenario budget, or reset it. ``scenario_cap`` is an integer from 6 through 32, or ``null`` to reset to the platform default of 12. The screenshot cap derives from it and moves with it, so the two can never starve each other. Raising is always allowed, includinglist_steering_rulesList this project's active and pending steering rules. Steering rules are prepended to every planning, development and QA prompt. Each rule has `state` (`active` = in the prompt, `pending` = waiting for a project member's approval, `expired` = past its expiry and no longer in the prompt) and `originapprove_steering_ruleApprove one pending steering rule so it reaches the iteration prompts. Pass the project id and the rule `id` from list_steering_rules. Only a `pending` rule changes; an already active rule returns `changed: false`. A retired rule is refused (409): approval never re-activates it. Your identity comesretire_steering_rulewrite/deleteRetire one steering rule so no later iteration prompt carries it. Pass the project id and the rule `id` from list_steering_rules. Works for an active or a pending rule, including a retro kaizen the automatic curation pass protects. The rule's text and history are kept and the retirement appears in Lreplan_taskwrite/deleteReplace an unretryable blocked task without losing its lineage. Creates a fresh, explicitly planned task under the same roadmap item and attempt lineage, transfers prerequisites and downstream dependents, and cancels the stale task with supersession provenance. The old PR, task, failures, criteria,remove_cancelled_dependencywrite/deleteList or remove a dependency on a task cancelled without delivery. ``escalation_id`` is a ``prerequisite_hold_stalled`` card. A waiting task whose dependency points at a task cancelled without proof of delivery can never start. Without ``task_id`` and ``predecessor_task_id`` this lists every such depcontrol_schedulerwrite/deleteStart, pause, or resume a project's autonomous work. `action` is one of: "enable" | "disable" | "resume" | "process_now". - enable/disable flip scheduler_enabled (the loop dispatches only enabled, status='active' projects). - resume clears a pause (peak/backoff/manual) so the project dispatches agaiarchive_projectwrite/deleteArchive a project (reversible shelve) — frees a project slot in-tool. Stops any in-flight machine, then flips the project to `archived`: it drops out of the per-tier project cap (freeing a slot for a new project) and the loop stops dispatching it, but the project + its history are kept and can be redelete_projectwrite/deleteSoft-delete a project (the harder option) — frees a slot and hides it. Stops any in-flight machine, then flips the project to `deleted`: it disappears from `list_projects`, drops out of the project cap, and the loop stops dispatching it. Deleting ALSO permanently purges the project's stored review arun_security_reviewFind security problems in a repository: a deep, whole-codebase review. Spawns a one-shot audit that scans the repo across a kind-aware taxonomy (secrets + git history, vulnerable/abandoned deps, injection, SSRF, path traversal, deserialization, crypto, info-leak, plus web authz/session/CORS, libraryrun_legal_exposure_reviewFind where a codebase creates legal exposure (privacy, consent, data handling). Spawns a one-shot review machine that reads the checkout offline and maps what the code DOES onto commonly cited legal obligations, filtered by the project's saved compliance profile (jurisdictions plus eleven product faget_legal_exposure_findingsRead a project's legal exposure findings, worst exposure first. Returns each finding as an OBSERVATION plus the obligation commonly cited over that pattern, its citation, the date the citation was last checked, and whether counsel has reviewed the registry entry (`counsel_reviewed`, false today forrun_control_gap_reviewStart a source-bound security control gap review for one project. The review records bounded engineering observations under the user's selected Cyber Essentials or CMMC Level 1 or Level 2 context. It does not determine framework standing, and it does not make changes. The `disclaimer_md` field mustget_control_gap_findingsRead a project's security-control observations and review boundaries. The result groups records by evidence class without a total or an overall framework outcome. `not_determinable` and `outside_review_scope` qualify every observation. An empty group does not establish that a control is in place, ananswer_requestwrite/deleteAnswer a thread's clarifying questions (status must be awaiting_answers). `answers` is a list of {"idx": <int from get_request_status>, "answer_md": <str, 1..2000 chars>}. Every question needs exactly one answer. The call flips the thread back to intake_pending; get_request_status reports the subseqrefine_requestwrite/deleteSay what is wrong with what a request produced, and have it reworked. Status must be "done". `feedback_md` is 1..1979 chars. Moves the thread to refine_pending; get_request_status reports the revised items. Refinement re-plans the thread's roadmap items and can EDIT OR HARD-DELETE the task rows it gsignupwrite/deleteCreate a Keelen account (or start agent login) — emails a 6-digit code. UNAUTHENTICATED — the only tool besides verify_email that works before a bearer key is configured. `email` is where the code is sent. Flow: signup(email) -> the user reads the 6-digit code from their inbox -> verify_email(email,verify_emailwrite/deleteRedeem the emailed 6-digit code for a reveal-once workspace API key. UNAUTHENTICATED. `email` + `code` must match a code issued by signup(email) within the last 15 minutes (5 attempts max). The returned `api_key` is shown exactly ONCE — store it ONLY in the MCP client config ("Authorization: Bearerget_onboarding_statusCheck what is set up so far and what to do next to get building. Reports engine_connected / github_connected / project_count / payment_status and a `next_action` string whose value is authoritative, with this tool polled between steps. `next_action` is "call_tool" (the tool named in `next_tool`, witopen_dashboardGet a one-click, pre-authenticated dashboard sign-in link for the owner. The engine-connect step — and any dashboard task (billing card update, a project page) — needs a signed-in browser. Because this server has already authenticated the workspace owner, this mints a single-use magic-link login tokconnect_githubGet the link that connects a GitHub account, so work can reach real repos. Returns an `install_url` that the user opens in a browser to pick the GitHub account/org, approve the install, and land on a "connected" page; get_onboarding_status() then reports github_connected true. The link expires in 10list_github_reposList repos the workspace's GitHub connection can see (for import_project). Each entry has full_name, default_branch, private, language, pushed_at. A `full_name` is what import_project(repo_full_name) connects. Reading the list can MINT a short-lived GitHub installation token, so this is not a pure rimport_projectwrite/deleteConnect an EXISTING GitHub repo as a Keelen project. This is the counterpart of create_project: it is for a repo that already exists, while create_project scaffolds a brand-new one. `repo_full_name` is "owner/repo" — it MUST be visible to the workspace's GitHub connection (list_github_repos() to broget_provisioning_statusCheck whether a new project has finished setting up and is ready to build. Returns overall (provisioning | ready | errored), a 7-stage checklist, and a user-facing error_kind when a stage failed. next_action is "wait" with poll_after_seconds (~10s) while provisioning, "wait" with NO poll_after_seconget_billingBilling status + a Stripe checkout link when a NEW subscription is needed. `plan` is one of starter | pro | agency (default starter). When the workspace has NO live subscription and needs one (open-signup unpaid, churned, or converting from a free/trial tier), returns a `checkout_url` with next_actiproject_digestRead a compact progress digest for one project (delivery, activity, holds, next decision). Returns the closed MCP projection: delivery counts and the five newest delivered items, a recent loop-activity count, current holds, the single highest-priority open decision, and `more_decisions`. Two steerinstop_iterationwrite/deleteStop one running iteration after confirmed runtime cleanup. Requires a personal active workspace owner. Workspace keys and Portfolio delegation cannot stop compute. The exact project iteration number binds the runtime. Cleanup failure leaves it active; a busy subject is refused. Confirmed cleanup fi
Tool changes
- 2026-10-22: list_projects, create_project, submit_request, get_request_status, set_product_vision, set_product_goal, list_roadmap, reorder_roadmap, cancel_roadmap_item, clear_horizon_pin, rollback_roblox_place, project_status
- 2026-10-21: list_projects, create_project, submit_request, get_request_status, set_product_vision, set_product_goal, list_roadmap, reorder_roadmap, cancel_roadmap_item, clear_horizon_pin, rollback_roblox_place, project_status
- 2026-10-19: list_projects, create_project, submit_request, get_request_status, set_product_vision, set_product_goal, list_roadmap, reorder_roadmap, cancel_roadmap_item, clear_horizon_pin, rollback_roblox_place, project_status
- 2026-10-17: list_projects, create_project, submit_request, get_request_status, set_product_vision, set_product_goal, list_roadmap, reorder_roadmap, cancel_roadmap_item, clear_horizon_pin, rollback_roblox_place, project_status
- 2026-10-16: list_projects, create_project, submit_request, get_request_status, set_product_vision, set_product_goal, list_roadmap, reorder_roadmap, cancel_roadmap_item, clear_horizon_pin, rollback_roblox_place, project_status
Repository · JSON · Text for agents · Registry updated 2026-08-19