Keelen

create_project

Destructive

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`org`	No
`name`	Yes
`engine`	No
`private`	No
`framework`	No
`ci_runs_on`	No
`project_kind`	Yes
`preview_command`	No
`build_description`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedAug 19, 2026

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare destructiveHint and readOnlyHint, and the description goes further by disclosing the OAuth-based account resolution, the possibility of actionable errors, the fallback next_action, and the best-effort compensation that deletes a just-created repo on failure. It also warns that labels not registered on an org runner will be rejected, which is valuable non-obvious behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured: purpose and routing are front-loaded, followed by parameter semantics, then behavior and response handling. Every sentence delivers a distinct constraint or useful fact, with no filler or repetition of schema fields that already have obvious meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, mutating 9-parameter tool, the description covers purpose, alternatives, parameter constraints, auth path, error behavior, compensation, and next-step guidance. The output schema already documents the return object, so the description appropriately focuses on how to consume next_step rather than restating fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Because the schema has 0% description coverage, the description carries the full burden and fully compensates. It explains every parameter, provides allowed values for project_kind, engine, and framework, clarifies conditional requirements like preview_command for web_app, and documents defaults such as private=True and ci_runs_on inheritance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear action: "Start building something new: creates a GitHub repo and begins work on it." It also explicitly contrasts with import_project and mentions list_github_repos, so an agent can distinguish it from closely related sibling tools without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ("ONLY when the user wants a NEW repo scaffolded") and when not to (existing repo should use import_project instead). It also gives precise conditional rules for project_kind, preview_command, engine credential requirements, org usage, and framework restrictions, leaving no ambiguity about valid invocation contexts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Keelen tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.