Skip to main content
Glama

Keelen

by io.github.jamie7893

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 repo is idempotent (returns the existing project with
already_exists=True). 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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stackNo
engineNo
project_kindNo
repo_full_nameYes
preview_commandNo
build_descriptionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.2/5.0
Behavior1/5

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

The description states that re-importing is idempotent ('Re-importing the same repo is idempotent...'), but the annotation declares `idempotentHint: false`. This is a direct contradiction. According to the rubric, any contradiction earns a score of 1 regardless of other disclosed behaviors.

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 long (~300 words) but every sentence earns its place given the tool's complexity. It is front-loaded with the core purpose, then structured logically by parameter, with edge cases and next steps clearly separated in paragraphs. There is no fluff or repetition; the density is justified by the 6 parameters and numerous conditional behaviors.

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?

The description is comprehensive for this complex tool. It covers idempotency (though contradicted), plan-allowance behavior, monorepo handling, detection pitfalls, parameter override authority, and post-call follow-ups. It also names the related tools to use in different flows. Since an output schema exists, the omission of return-value details is acceptable. Nothing an agent needs to call this correctly is missing.

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?

With schema description coverage at 0%, the description carries full responsibility for parameter documentation. It thoroughly explains each parameter: `repo_full_name` format and visibility requirements, `engine` options and credential prerequisites, `build_description` purpose and recommendation, `project_kind` values, monorepo detection caveats, `stack` usage, and `preview_command` requirements for web_app. This goes far beyond the bare schema.

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 clearly states the tool's purpose: 'Connect an EXISTING GitHub repo as a Keelen project.' It explicitly frames it as the counterpart to create_project and distinguishes the two use cases. This is a specific verb+resource with clear differentiation from its sibling.

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 provides explicit guidance on when to use this tool versus alternatives: 'use THIS tool when the user already has a repo, and create_project only to scaffold a brand-new one.' It also references related tools like list_github_repos, submit_request, get_billing, and get_provisioning_status, explaining the expected next steps in various scenarios.

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

All Keelen toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Every tool targets a distinct resource and action duo, even within clusters like request handling or security reviews. The get_ vs run_ pairs are clearly separated, and descriptions explicitly contrast confusing alternatives such as archive_project vs delete_project.

Naming Consistency4/5

The set overwhelmingly follows verb_noun snake_case (submit_request, list_projects, resolve_escalation). The one visible deviation is project_status, which breaks the get_/pattern, and signup is a single-word verb instead of sign_up.

Tool Count2/5

37 tools is well above the 25+ threshold and spans auth, billing, project lifecycle, roadmap, escalations, product documents, and multiple review types. Most tools earn their place, but the surface is too large for one server and would be more coherent split into focused servers.

Completeness4/5

The domain coverage is broad: full project lifecycle, request intake/refinement, roadmap manipulation, escalation handling, product doc read/write, and security/legal review flows. Minor gaps exist, most notably no dedicated task-listing or task-update tool, but agents can work around these via project_status and list_escalations.

Resources