MCP-Server
Keelen
io.github.jamie7893/keelen
Was dieses MCP kann
Manages autonomous software projects connected to GitHub, including repository setup, roadmap intake, task execution, scheduling, project status, escalations, and delivery workflows.
Funktionen
Tools
41
Tools
answer_request
Answer 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>}. Answer EVERY question exactly once. Flips the thread
back to intake_pending; poll get_request_status again.
Destruktiv
Externer Zugriff
Eingabeschema
{'type': 'object', 'title': 'answer_requestArguments', 'required': ['project_id', 'thread_id', 'answers'], 'properties': {'answers': {'type': 'array', 'items': {'type': 'object', 'additionalProperties': True}, 'title': 'Answers'}, 'thread_id': {'type': 'string', 'title': 'Thread Id'}, 'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'answer_requestOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
archive_project
Archive 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
restored from the dashboard project page. Stopping a machine DESTROYS the
running process state â restoring the project later cannot bring that
execution back, so this is destructive despite being reversible. A replay on
an already-archived project changes no row, but is not idempotent end to end.
Prefer this over `delete_project` unless you specifically want the project
gone. Owner-scoped (an MCP key is owner-only); a project not in the
workspace 404s.
Destruktiv
Eingabeschema
{'type': 'object', 'title': 'archive_projectArguments', 'required': ['project_id'], 'properties': {'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'archive_projectOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
cancel_roadmap_item
Cancel / close a single roadmap item (get its id from list_roadmap).
Use this to close a DELIVERED or duplicate item that keeps re-parking: when
the work already shipped, every expand produces no dev-ready tasks and files a
recurring `roadmap_item_parked` escalation you have to keep acking. 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 (retry once that iter
ends).
Returns {id, status, changed, next_step}.
Eingabeschema
{'type': 'object', 'title': 'cancel_roadmap_itemArguments', 'required': ['project_id', 'item_id'], 'properties': {'item_id': {'type': 'string', 'title': 'Item Id'}, 'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'cancel_roadmap_itemOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
clear_horizon_pin
Clear 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 â use cancel_roadmap_item
to close a delivered item. Returns {id, previous_pin, horizon_pin, next_step}.
Eingabeschema
{'type': 'object', 'title': 'clear_horizon_pinArguments', 'required': ['project_id', 'item_id'], 'properties': {'item_id': {'type': 'string', 'title': 'Item Id'}, 'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'clear_horizon_pinOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
close_task
Close a task that should not be built â a duplicate, or work already shipped.
Use this when a task on the board 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, QA steps, iterations) â nothing is deleted.
`reason` is REQUIRED and is recorded on the audit trail; say why in one
line. Pass `superseded_by_pr_number` (or `superseded_by_task_id`) when the
work was genuinely delivered somewhere else â that records verified
provenance instead of a bare abandon. Closing does NOT claim the content is
on the default branch, so any task that declared a dependency on this one
keeps waiting; deliver or re-plan those separately.
Refuses with 409 while the task is being worked on by a running iteration
(stop the machine first, or wait for it to finish). A task in another
workspace 404s. Business-level replay guard: closing an already-closed task
changes no task state. The call is not idempotent end to end â an
authenticated request also persists credential-use state.
The response echoes `open_tasks`: how many tasks are still open on the
project, counted after the close commits. Check it â if it did not drop,
the ticket was already closed and this call changed nothing. It is the same
count `project_status` returns, and neither counts a closed task as open.
Prefer this over leaving a dead task on the board: unfinished tasks count
against the project's planning capacity, so stale duplicates quietly stop
new roadmap items from being expanded.
Destruktiv
Externer Zugriff
Eingabeschema
{'type': 'object', 'title': 'close_taskArguments', 'required': ['project_id', 'task_id', 'reason'], 'properties': {'reason': {'type': 'string', 'title': 'Reason'}, 'task_id': {'type': 'string', 'title': 'Task Id'}, 'project_id': {'type': 'string', 'title': 'Project Id'}, 'superseded_by_task_id': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Superseded By Task Id', 'default': None}, 'superseded_by_pr_number': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'title': 'Superseded By Pr Number', 'default': None}}}
Ausgabeschema
{'type': 'object', 'title': 'close_taskOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
connect_github
Get the link that connects a GitHub account, so work can reach real repos.
Returns an `install_url` â send it to the user to open in a browser. They
pick the GitHub account/org, approve the install, and land on a "connected"
page; then poll get_onboarding_status() until github_connected is true. The
link expires in 10 minutes â call connect_github() again for a fresh one.
Eingabeschema
{'type': 'object', 'title': 'connect_githubArguments', 'properties': {}}
Ausgabeschema
{'type': 'object', 'title': 'connect_githubOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
control_scheduler
Start, 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 again.
- process_now durably prioritizes and immediately attempts the next intake
batch, independent of the dev scheduler switch. A gate returns a typed
reason and recovery step instead of a spawn promise.
- enable/resume can execute pending refinement that DELETES tasks, and
process_now can start an intake batch, so treat this tool as destructive
even when the echoed scheduler state looks unchanged.
Returns the resulting scheduler state.
Destruktiv
Externer Zugriff
Eingabeschema
{'type': 'object', 'title': 'control_schedulerArguments', 'required': ['project_id', 'action'], 'properties': {'action': {'type': 'string', 'title': 'Action'}, 'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'control_schedulerOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
create_project
Start building something new: creates a GitHub repo and begins work on it.
Use this ONLY when the user wants a NEW repo scaffolded. If they already
have a repo, use import_project(repo_full_name) instead â this tool would
create a second, empty one beside theirs (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}; follow next_step (poll 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.
Destruktiv
Externer Zugriff
Eingabeschema
{'type': 'object', 'title': 'create_projectArguments', 'required': ['name', 'build_description', 'project_kind'], 'properties': {'org': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Org', 'default': None}, 'name': {'type': 'string', 'title': 'Name'}, 'engine': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Engine', 'default': None}, 'private': {'type': 'boolean', 'title': 'Private', 'default': True}, 'framework': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Framework', 'default': None}, 'ci_runs_on': {'anyOf': [{'type': 'array', 'items': {'type': 'string'}}, {'type': 'null'}], 'title': 'Ci Runs On', 'default': None}, 'project_kind': {'type': 'string', 'title': 'Project Kind'}, 'preview_command': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Preview Command', 'default': None}, 'build_description': {'type': 'string', 'title': 'Build Description'}}}
Ausgabeschema
{'type': 'object', 'title': 'create_projectOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
delete_project
Soft-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 artifacts. The row is retained for audit and re-importing the repo
restores that deleted row in place (unlike `archive_project` there is no
in-tool restore), but the purged artifacts are gone for good and the stopped
workers' process state cannot be recreated. A replay on a deleted project
changes no row; the call is not idempotent end to end. Owner-scoped; a
project not in the workspace 404s.
Destruktiv
Eingabeschema
{'type': 'object', 'title': 'delete_projectArguments', 'required': ['project_id'], 'properties': {'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'delete_projectOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
get_billing
Billing 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_action "browser" â send it to the user to open in a browser (the
one setup step that can't happen in chat). Compute unlocks automatically
once payment completes (a Stripe webhook flips the workspace to active);
you do not need to block on it. A past_due workspace gets NO checkout â
the fix is a card update in the dashboard billing page (a new checkout
would create a second subscription); follow next_step. Subscribed or
suspended-with-subscription states return checkout_url=None with an
explanatory next_step.
Eingabeschema
{'type': 'object', 'title': 'get_billingArguments', 'properties': {'plan': {'type': 'string', 'title': 'Plan', 'default': 'starter'}}}
Ausgabeschema
{'type': 'object', 'title': 'get_billingOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
get_control_gap_findings
Read a project's security-control observations and review boundaries.
The result groups records by evidence class without a total or an overall
framework outcome. Read `not_determinable` and `outside_review_scope`
before describing any observation. An empty group does not establish that
a control is in place, and `disclaimer_md` must reach the user.
`limit` defaults to 25 (max 100). `include_all` includes resolved,
dismissed, and out-of-scope records. This read-only tool has no compute
quota and remains available after the trigger closes for a project.
Eingabeschema
{'type': 'object', 'title': 'get_control_gap_findingsArguments', 'required': ['project_id'], 'properties': {'limit': {'type': 'integer', 'title': 'Limit', 'default': 25}, 'project_id': {'type': 'string', 'title': 'Project Id'}, 'include_all': {'type': 'boolean', 'title': 'Include All', 'default': False}}}
Ausgabeschema
{'type': 'object', 'title': 'get_control_gap_findingsOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
get_legal_exposure_findings
Read 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 for every entry). `exposure_order` is an ORDER, never a score:
there is no grade, no percentage, and no overall state in this output.
Read `not_determinable` before you summarise: those are checks that could
not reach a verdict, and leaving them out would turn a partial review into
a clean answer. The `disclaimer_md` field must reach the user.
`limit` defaults to 25 (max 100). `include_all` adds resolved, dismissed,
and out-of-scope rows to the default actionable set. Read-only, no compute,
no rate limit; it works even while the trigger is closed for the project.
Eingabeschema
{'type': 'object', 'title': 'get_legal_exposure_findingsArguments', 'required': ['project_id'], 'properties': {'limit': {'type': 'integer', 'title': 'Limit', 'default': 25}, 'project_id': {'type': 'string', 'title': 'Project Id'}, 'include_all': {'type': 'boolean', 'title': 'Include All', 'default': False}}}
Ausgabeschema
{'type': 'object', 'title': 'get_legal_exposure_findingsOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
get_onboarding_status
Check 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 you should follow VERBATIM, polling this tool
between steps. `next_action` is "call_tool" (call the tool named in
`next_tool`, following `next_step`) until onboarding is complete, then
"done". (`next_action_detail` echoes the pre-2026-07-29 dict shape and is
DEPRECATED â it is removed 2026-10-29; read next_action/next_tool instead.)
- engine step: send the user the dashboard /login link. Engine subscriptions
(Claude / Codex / GLM) are connected in the DASHBOARD for security â
NEVER ask for or paste engine credentials in this chat.
- github step: call connect_github() for an install link.
- project step: create_project(...) for a new repo, or
import_project(repo_full_name) for an existing one.
- launch step: poll get_provisioning_status(project_id) until ready.
Re-checking is YOUR job â the server does not push.
Also returns a `usage` block (pool / daily / machine-hours counters + tier
caps) for capacity-aware automation clients.
Eingabeschema
{'type': 'object', 'title': 'get_onboarding_statusArguments', 'properties': {}}
Ausgabeschema
{'type': 'object', 'title': 'get_onboarding_statusOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
get_product_goal
Read a project's current product goal (the outcome work is aimed at).
READ THIS BEFORE YOU CALL `set_product_goal`: the setter REPLACES the whole
document rather than appending to it, so writing without reading first
silently discards whatever the user already recorded. To add a line, read
the current text, edit it, and set the full result back.
Returns {project_id, product_goal_md, updated_at}. `product_goal_md` is
None when no goal has been set. Tenant-scoped: a project not in the
caller's workspace 404s.
Eingabeschema
{'type': 'object', 'title': 'get_product_goalArguments', 'required': ['project_id'], 'properties': {'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'get_product_goalOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
get_product_vision
Read a project's current product vision (what the product is for).
READ THIS BEFORE YOU CALL `set_product_vision`: the setter REPLACES the
whole document rather than appending to it, so writing without reading
first silently discards whatever the user already recorded. To add a line,
read the current text, edit it, and set the full result back.
Returns {project_id, product_vision_md, updated_at}. `product_vision_md` is
None when no vision has been set. Tenant-scoped: a project not in the
caller's workspace 404s.
Eingabeschema
{'type': 'object', 'title': 'get_product_visionArguments', 'required': ['project_id'], 'properties': {'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'get_product_visionOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
get_provisioning_status
Check 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 or errored, and "done" when
overall is 'ready' â then steer the loop with submit_request(project_id,
text). Reaching 'ready' also PERSISTS the owner's onboarding-completion
state, so this is not a pure read. Tenant-scoped: a project not in the
caller's workspace 404s.
Eingabeschema
{'type': 'object', 'title': 'get_provisioning_statusArguments', 'required': ['project_id'], 'properties': {'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'get_provisioning_statusOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
get_request_status
Check what happened to a request, and read any questions it asked back.
Intake is async (~5min cadence) - poll periodically. Read `next_action`:
"wait" (still processing), "answer_questions" (call answer_request with one
answer per question), "done" (see generated_roadmap_item_ids), "cancelled"
(terminal, no items), "failed" (see intake_failure_reason).
Eingabeschema
{'type': 'object', 'title': 'get_request_statusArguments', 'required': ['project_id', 'thread_id'], 'properties': {'thread_id': {'type': 'string', 'title': 'Thread Id'}, 'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'get_request_statusOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
import_project
Connect an EXISTING GitHub repo as a Keelen project.
This is the counterpart of create_project: use THIS tool when the user
already has a repo, and create_project only to scaffold a brand-new one.
`repo_full_name` is "owner/repo" â it MUST be visible to the workspace's
GitHub connection (list_github_repos() to browse; a non-visible repo 404s).
`engine` is OPTIONAL â one of claude_code | codex | glm | kimi | grok
(defaults to claude_code); codex/glm/kimi/grok require a matching connected
credential.
`build_description` is OPTIONAL but STRONGLY recommended â a plain-language
"what should Keelen build first?" submitted as the project's first Request so
the loop has work; an imported project with no Request sits idle until you
call submit_request(project_id, ...).
`project_kind` is OPTIONAL â one of library | node_library | python_library |
service | cli | web_app | godot_game | roblox_game | unknown. Omit it and the
kind is auto-detected. PASS IT when the repo is a MONOREPO (apps in
subdirectories), a stack with no standard root manifest (Java, Ruby, PHP,
.NET, Elixir), or when you want a classification detection cannot infer â
in those cases detection yields "unknown", which BLOCKS the dev lane until
someone overrides it. A value you pass is authoritative and is never
overwritten by later auto-detection. `stack` is the OPTIONAL language axis
(python | node | rust | go | cpp) for a language-agnostic kind.
`preview_command` is REQUIRED when project_kind is "web_app" (the command
that serves the app locally, e.g. "npm run dev") and optional otherwise,
where it overrides the detected one.
Re-importing the same live repo is replay-guarded (returns the existing
project with already_exists=True), and re-importing a SOFT-DELETED repo
RESTORES that deleted row in place â it does not create a fresh project.
Restored queued work can include refinement that deletes tasks, and the call
is not idempotent end to end. On a plan with no scheduled-project allowance
the project is still created but with the loop OFF â next_step then steers to
get_billing(). Otherwise follow next_step and poll
get_provisioning_status(project_id).
Destruktiv
Externer Zugriff
Eingabeschema
{'type': 'object', 'title': 'import_projectArguments', 'required': ['repo_full_name'], 'properties': {'stack': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Stack', 'default': None}, 'engine': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Engine', 'default': None}, 'project_kind': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Project Kind', 'default': None}, 'repo_full_name': {'type': 'string', 'title': 'Repo Full Name'}, 'preview_command': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Preview Command', 'default': None}, 'build_description': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Build Description', 'default': None}}}
Ausgabeschema
{'type': 'object', 'title': 'import_projectOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
list_escalations
See 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 "forever-paused" project with no open
`project_pause` row is surfaced as a synthetic `orphan:<project_id>` row.
Each row carries a server-derived `task_retry_available` flag and an exact
`next_tool`: eligible recovery blocks route to `retry_blocked_task`, roadmap
parks to `rearm_roadmap_item`, platform conflicts to their structured
resolver, stale work to `replan_task`, and only safe auxiliary cards to
`resolve_escalation`.
Eingabeschema
{'type': 'object', 'title': 'list_escalationsArguments', 'required': ['project_id'], 'properties': {'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'list_escalationsOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
list_github_repos
List repos the workspace's GitHub connection can see (for import_project).
Each entry has full_name, default_branch, private, language, pushed_at. Pass
a `full_name` to import_project(repo_full_name) to connect it. Reading the
list can MINT a short-lived GitHub installation token, so this is not a pure
read. Returns 409 if GitHub isn't connected yet â call connect_github()
first.
Eingabeschema
{'type': 'object', 'title': 'list_github_reposArguments', 'properties': {}}
Ausgabeschema
{'type': 'object', 'title': 'list_github_reposOutput', 'required': ['result'], 'properties': {'result': {'type': 'array', 'items': {'type': 'object', 'additionalProperties': True}, 'title': 'Result'}}}
list_projects
List the projects in this workspace, with what each one is building.
Eingabeschema
{'type': 'object', 'title': 'list_projectsArguments', 'properties': {}}
Ausgabeschema
{'type': 'object', 'title': 'list_projectsOutput', 'required': ['result'], 'properties': {'result': {'type': 'array', 'items': {'type': 'object', 'additionalProperties': True}, 'title': 'Result'}}}
list_roadmap
See 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`:
crash_capped | noop_capped | crash_cooldown | noop_cooldown |
awaiting_intake_thread | held_on_open_pr | other). A skipped item ahead of
yours does not delay it.
Eingabeschema
{'type': 'object', 'title': 'list_roadmapArguments', 'required': ['project_id'], 'properties': {'status': {'type': 'string', 'title': 'Status', 'default': 'queued'}, 'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'list_roadmapOutput', 'required': ['result'], 'properties': {'result': {'type': 'array', 'items': {'type': 'object', 'additionalProperties': True}, 'title': 'Result'}}}
open_dashboard
Get 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
token and returns a `/login?token=â¦` deep link: opening it signs the user
straight into the dashboard (no email round-trip, no password) and lands
them where onboarding left off. Send the user the returned `login_url`; it
works once and expires in 15 minutes â call again for a fresh one.
Eingabeschema
{'type': 'object', 'title': 'open_dashboardArguments', 'properties': {}}
Ausgabeschema
{'type': 'object', 'title': 'open_dashboardOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
project_status
Check 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. Use list_roadmap to inspect 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 report it
as "waiting for off-peak", never as 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.
Eingabeschema
{'type': 'object', 'title': 'project_statusArguments', 'required': ['project_id'], 'properties': {'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'project_statusOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
rearm_roadmap_item
Run the dashboard's replay-guarded same-item dependency re-arm.
Pass 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``, and
resolves the matching cards in one transaction. A bounded live GitHub check
may be used when the local merge state is stale, so a call can reach out
even when the re-arm itself changes nothing.
Externer Zugriff
Eingabeschema
{'type': 'object', 'title': 'rearm_roadmap_itemArguments', 'required': ['escalation_id'], 'properties': {'escalation_id': {'type': 'string', 'title': 'Escalation Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'rearm_roadmap_itemOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
refine_request
Say what is wrong with what a request produced, and have it reworked.
Status must be "done". `feedback_md` is 1..2000 chars. Moves the thread to
refine_pending; poll get_request_status to see the revised items. Refinement
re-plans the thread's roadmap items and can EDIT OR HARD-DELETE the task rows
it generated earlier (the machine patch-tasks endpoint deletes them
outright), so treat this as destructive: up to five refinements per thread
each carry that power.
Destruktiv
Externer Zugriff
Eingabeschema
{'type': 'object', 'title': 'refine_requestArguments', 'required': ['project_id', 'thread_id', 'feedback_md'], 'properties': {'thread_id': {'type': 'string', 'title': 'Thread Id'}, 'project_id': {'type': 'string', 'title': 'Project Id'}, 'feedback_md': {'type': 'string', 'title': 'Feedback Md'}}}
Ausgabeschema
{'type': 'object', 'title': 'refine_requestOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
reorder_roadmap
Change what gets built first.
`ordered_ids` is the desired front-to-back order of queued roadmap-item ids
(get them from list_roadmap). 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}.
Eingabeschema
{'type': 'object', 'title': 'reorder_roadmapArguments', 'required': ['project_id', 'ordered_ids'], 'properties': {'project_id': {'type': 'string', 'title': 'Project Id'}, 'ordered_ids': {'type': 'array', 'items': {'type': 'string'}, 'title': 'Ordered Ids'}}}
Ausgabeschema
{'type': 'object', 'title': 'reorder_roadmapOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
replan_task
Replace 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, and evidence remain in the audit history; nothing is
marked delivered.
Destruktiv
Externer Zugriff
Eingabeschema
{'type': 'object', 'title': 'replan_taskArguments', 'required': ['project_id', 'task_id', 'title', 'body_md', 'acceptance_criteria', 'decision_md'], 'properties': {'title': {'type': 'string', 'title': 'Title'}, 'body_md': {'type': 'string', 'title': 'Body Md'}, 'task_id': {'type': 'string', 'title': 'Task Id'}, 'project_id': {'type': 'string', 'title': 'Project Id'}, 'decision_md': {'type': 'string', 'title': 'Decision Md'}, 'acceptance_criteria': {'type': 'array', 'items': {'type': 'string'}, 'title': 'Acceptance Criteria'}}}
Ausgabeschema
{'type': 'object', 'title': 'replan_taskOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
resolve_escalation
Acknowledge 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
task_block/operator_action cannot be acknowledged: use its typed retry,
platform-policy resolution, replan, close, or supersede operation instead.
The acknowledgement itself is replay-guarded (a repeat changes nothing), but
the call is not idempotent end to end: resuming a paused project lets queued
refinement run, and that refinement can DELETE tasks. Accepts a real
escalation UUID or a synthetic `orphan:<project_id>`.
Destruktiv
Externer Zugriff
Eingabeschema
{'type': 'object', 'title': 'resolve_escalationArguments', 'required': ['escalation_id', 'decision_md'], 'properties': {'decision_md': {'type': 'string', 'title': 'Decision Md'}, 'escalation_id': {'type': 'string', 'title': 'Escalation Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'resolve_escalationOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
resolve_platform_policy_conflict
Resolve a platform-policy dead-end with a structured plan decision.
``decision`` is one of ``reuse_existing_evidence``, ``split_task``,
``raise_project_cap``, or ``remove_scenario``. ``raise_project_cap`` also
requires ``project_cap`` (6..32). The decision becomes a new task-plan
section; the same task lineage is requeued before the escalation resolves.
On a project that runs the ui-review evidence lifecycle (``ui-review.json``
is a retained evidence catalog), ``raise_project_cap`` changes the
per-run capture budget -- how many scenarios one capture run holds -- not
catalog capacity: the catalog has no scenario limit, so no decision is
needed to make room in it.
On a ``web_app`` task, ``reuse_existing_evidence`` also repairs a frozen
theme-only collision in the same transaction: criteria whose evidence specs
differ only by a light/dark variant token (for example
``setup-timeline-light`` and ``setup-timeline-dark``) are refrozen to one
shared cell that lists the required ``themes``, the old and new specs are
audited, and the plan tells the worker to cover that cell with one
scenario. Every criterion keeps its row and alias; unrelated specs are not
changed.
Externer Zugriff
Eingabeschema
{'type': 'object', 'title': 'resolve_platform_policy_conflictArguments', 'required': ['escalation_id', 'decision', 'decision_md'], 'properties': {'decision': {'type': 'string', 'title': 'Decision'}, 'decision_md': {'type': 'string', 'title': 'Decision Md'}, 'project_cap': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'title': 'Project Cap', 'default': None}, 'escalation_id': {'type': 'string', 'title': 'Escalation Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'resolve_platform_policy_conflictOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
retry_blocked_task
Grant one fresh attempt after fixing a recovery-budget task block.
Pass 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
remains acknowledgement-only for task blocks. Business-level replay guard:
an already-retried block is not retried again; the call is not idempotent end
to end, because an authenticated request also persists credential-use state.
Externer Zugriff
Eingabeschema
{'type': 'object', 'title': 'retry_blocked_taskArguments', 'required': ['escalation_id', 'decision_md'], 'properties': {'decision_md': {'type': 'string', 'title': 'Decision Md'}, 'escalation_id': {'type': 'string', 'title': 'Escalation Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'retry_blocked_taskOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
rollback_roblox_place
Roll 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` (get published versions from the web Roblox Publishing card)
â 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 (retry); an invalid or unscoped Open Cloud key â 409 /
403. Returns {version_number, env, published_at, status, next_step}.
Destruktiv
Externer Zugriff
Eingabeschema
{'type': 'object', 'title': 'rollback_roblox_placeArguments', 'required': ['project_id', 'version_number'], 'properties': {'project_id': {'type': 'string', 'title': 'Project Id'}, 'version_number': {'type': 'integer', 'title': 'Version Number'}}}
Ausgabeschema
{'type': 'object', 'title': 'rollback_roblox_placeOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
run_control_gap_review
Start 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 must be
repeated to the user before any observation is summarised.
The project needs a saved framework profile, an eligible plan, and a place
on the operator allowlist. Billable; one review is allowed in flight per
project. Refusals return `ok: false` with a next step and do not start work.
Rate-limited per workspace.
Eingabeschema
{'type': 'object', 'title': 'run_control_gap_reviewArguments', 'required': ['project_id'], 'properties': {'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'run_control_gap_reviewOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
run_legal_exposure_review
Find 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
facts). Findings land on the project's Legal page for a human to triage,
and you read them with get_legal_exposure_findings. No change is ever
applied automatically.
THIS IS NOT LEGAL ADVICE AND IT IS NOT A LEGAL CLEARANCE. The result
carries a `disclaimer_md` field: repeat it to the user before you summarise
anything. The review is not exhaustive, so an empty result is never proof
that anything is in order.
Requires a saved compliance profile (409-shaped refusal without one),
a plan that carries the feature, and the project on the operator allowlist.
Billable; one review in flight per project. Every refusal comes back as
`ok: false` with an actionable `next_step`, and starts nothing.
Rate-limited per workspace.
Eingabeschema
{'type': 'object', 'title': 'run_legal_exposure_reviewArguments', 'required': ['project_id'], 'properties': {'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'run_legal_exposure_reviewOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
run_security_review
Find 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,
library API-misuse, game client-trust, or infra/CI as applicable) and posts
findings to the project's Security review for human triage. You review the
findings, then send the ones worth fixing into the loop as Requests; no fix
is applied automatically. Billable; one audit in-flight per project.
(Triggering is disabled while the feature is hardened for production: a
project not on the operator allowlist â empty by default â returns a message
instead of spawning; earlier results stay visible.) Requires a paid plan;
a free or trial workspace gets a message telling the user to upgrade.
Eingabeschema
{'type': 'object', 'title': 'run_security_reviewArguments', 'required': ['project_id'], 'properties': {'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'run_security_reviewOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
set_product_goal
Set 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}.
Destruktiv
Eingabeschema
{'type': 'object', 'title': 'set_product_goalArguments', 'required': ['project_id', 'goal_md'], 'properties': {'goal_md': {'type': 'string', 'title': 'Goal Md'}, 'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'set_product_goalOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
set_product_vision
Say 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}.
Destruktiv
Eingabeschema
{'type': 'object', 'title': 'set_product_visionArguments', 'required': ['project_id', 'vision_md'], 'properties': {'vision_md': {'type': 'string', 'title': 'Vision Md'}, 'project_id': {'type': 'string', 'title': 'Project Id'}}}
Ausgabeschema
{'type': 'object', 'title': 'set_product_visionOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
set_ui_review_scenario_cap
Set 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, including from a completely full manifest.
LOWERING is refused when the default branch already declares more scenarios
or screenshots than the smaller budget allows, and is also refused when that
manifest cannot be read â both caps are enforced when keelen pushes and not
in your CI, so an over-cap manifest fails every push while CI stays green.
On a project with the retained evidence catalog (the response carries
``evidence_lifecycle: true``) the same parameter is a CAPTURE-RUN setting:
it limits how many scenarios and screenshots one capture run holds, a pull
request that needs more is split into capture batches, and the catalog
keeps every scenario whatever the value. The response then also reports
``catalog`` (the retained counts) separately from ``run_limits``, and a
lower is not refused for catalog size once the catalog is migrated.
Read ``project_status.ui_review`` first to see the live occupancy. Repeated
calls with the same value change nothing.
Eingabeschema
{'type': 'object', 'title': 'set_ui_review_scenario_capArguments', 'required': ['project_id'], 'properties': {'project_id': {'type': 'string', 'title': 'Project Id'}, 'scenario_cap': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'title': 'Scenario Cap', 'default': None}}}
Ausgabeschema
{'type': 'object', 'title': 'set_ui_review_scenario_capOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
signup
Create 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, code) returns a reveal-once API key -> save it as this
server's `Authorization: Bearer <api_key>` header in your MCP client config
-> reconnect -> get_onboarding_status() to continue setup. The code expires
in 15 minutes; call signup again to resend. Response is uniform whether or
not the email already has an account (enumeration-safe), so signup doubles
as agent LOGIN. Rate-limited per IP and per email.
ASK THE USER for `email` in chat and WAIT for their answer before calling
this. Do NOT infer it from your client profile, the logged-in account, git
config, or any other ambient source; if you already hold a candidate, echo
it back and get an explicit yes first. Because this call doubles as LOGIN, a
guessed address signs the user in to whatever workspace owns it, and the
rest of setup then mints an API key on, and creates a project in, an account
they did not choose.
Destruktiv
Externer Zugriff
Eingabeschema
{'type': 'object', 'title': 'signupArguments', 'required': ['email'], 'properties': {'email': {'type': 'string', 'title': 'Email'}}}
Ausgabeschema
{'type': 'object', 'title': 'signupOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
submit_request
Ask for a change in plain English: a feature, a bug fix, or a new direction.
Submit ONE feature or intent per call; split a multi-feature ask into
separate requests. `text` must be under 16000 characters. Returns
{thread_id, status, next_action, poll_after_seconds, next_step}; follow
next_step (re-check get_request_status after poll_after_seconds).
Externer Zugriff
Eingabeschema
{'type': 'object', 'title': 'submit_requestArguments', 'required': ['project_id', 'text'], 'properties': {'text': {'type': 'string', 'title': 'Text'}, 'project_id': {'type': 'string', 'title': 'Project Id'}, 'workflow_profile': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Workflow Profile', 'default': None}}}
Ausgabeschema
{'type': 'object', 'title': 'submit_requestOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
verify_email
Redeem 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: Bearer <api_key>"), NEVER in a repo or a file you might
commit. Then reconnect this server with the header set and call
get_onboarding_status(). An invalid/expired/consumed code returns a uniform
error â call signup(email) for a fresh one.
Destruktiv
Eingabeschema
{'type': 'object', 'title': 'verify_emailArguments', 'required': ['email', 'code'], 'properties': {'code': {'type': 'string', 'title': 'Code'}, 'email': {'type': 'string', 'title': 'Email'}}}
Ausgabeschema
{'type': 'object', 'title': 'verify_emailOutput', 'required': ['result'], 'properties': {'result': {'type': 'object', 'title': 'Result', 'additionalProperties': True}}}
Verlauf
Letzte Tool-Änderungen
Geändert
set_ui_review_scenario_cap
1. October 2026 02:45
Geändert
resolve_platform_policy_conflict
1. October 2026 02:45
Geändert
submit_request
27. September 2026 02:44
Geändert
get_billing
21. September 2026 02:51
Geändert
get_provisioning_status
21. September 2026 02:51
Geändert
import_project
21. September 2026 02:51
Geändert
list_github_repos
21. September 2026 02:51
Geändert
connect_github
21. September 2026 02:51
Geändert
get_onboarding_status
21. September 2026 02:51
Geändert
verify_email
21. September 2026 02:51
Geändert
signup
21. September 2026 02:51
Geändert
refine_request
21. September 2026 02:51
Geändert
answer_request
21. September 2026 02:51
Geändert
get_control_gap_findings
21. September 2026 02:51
Geändert
run_control_gap_review
21. September 2026 02:51
Geändert
get_legal_exposure_findings
21. September 2026 02:51
Geändert
run_legal_exposure_review
21. September 2026 02:51
Geändert
run_security_review
21. September 2026 02:51
Geändert
delete_project
21. September 2026 02:51
Geändert
archive_project
21. September 2026 02:51
Geändert
control_scheduler
21. September 2026 02:51
Geändert
replan_task
21. September 2026 02:51
Geändert
set_ui_review_scenario_cap
21. September 2026 02:51
Geändert
resolve_platform_policy_conflict
21. September 2026 02:51
Geändert
rearm_roadmap_item
21. September 2026 02:51
Geändert
retry_blocked_task
21. September 2026 02:51
Geändert
resolve_escalation
21. September 2026 02:51
Geändert
list_escalations
21. September 2026 02:51
Geändert
get_product_vision
21. September 2026 02:51
Geändert
get_product_goal
21. September 2026 02:51
Entdecken
Ähnliche MCP-Server
2ools
app.2ools/mcp
Builds, versions, reviews, deploys, shares, and coordinates work on websites, web applications, and games through project workflo…
Kaiku
tech.kaiku/kaiku
Manages team issues, comments, attachments, projects, wiki pages, and related development workflows.
SmartTools
io.github.9thShini/smart-tools
Provides general-purpose calculators, unit converters, text and data transformations, hashing, code-generation helpers, and forma…
Wakatime
io.github.pipeworx-io/wakatime
Provides WakaTime coding-activity data, including durations, projects, commits, goals, heartbeats, editor usage, leaders, and use…
TaskLite
net.tasklite/mcp
Builds and manages hosted project backends, structured boards, REST APIs, automations, authentication access, databases, and fron…
Linear
io.github.pipeworx-io/linear
Manages and searches Linear teams and issues, including issue creation and detailed issue retrieval.
Jira
io.github.pipeworx-io/jira
Searches Jira issues and retrieves project, issue, status, assignee, priority, comment, attachment, and linked-issue details.
Crontab
io.github.pipeworx-io/crontab
Parses cron expressions, validates them, explains their schedules, and computes upcoming run times.