Skip to main content
Glama

Import Repository

import_project
Destructive

Connect 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". Import requires that the SAME caller
listed the repository with list_github_repos() within the last 10 minutes,
OR that the workspace already holds a valid repository grant. An absent or
expired authorization returns code `repository_access_required`; call
list_github_repos() again, then retry. Missing, expired, foreign and
nonexistent repositories share that same generic denial, so the tool never
reveals whether a guessed repository exists.
`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
submit_request(project_id, ...) adds one.

`project_kind` is OPTIONAL — one of library | node_library | python_library |
service | cli | web_app | godot_game | roblox_game | mobile_app | unknown.
Omit it and the kind is auto-detected. It is required for a MONOREPO (apps in
subdirectories), a stack with no standard root manifest (Java, Ruby, PHP,
.NET, Elixir), or a classification detection cannot infer — detection yields
"unknown" there, which BLOCKS the dev lane until
someone overrides it. A supplied value 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.

A root **Expo** repository imports as `mobile_app` under a conservative,
Expo-only contract. Recognition requires a root `package.json` declaring
both `expo` and `react-native` plus root Expo config evidence, resolved in
documented precedence order (first present wins): dynamic app.config.ts,
app.config.mts, app.config.cts, app.config.mjs, app.config.cjs,
app.config.js by FILENAME PRESENCE only, then static app.config.json, then
app.json. Imported config is inspected as data and never executed; a nested
config, config-free Expo package, ordinary Node package, or unreadable root
probe does not qualify — unreadable evidence stays `unknown` instead of
manufacturing a mobile result. Mobile is a Node toolchain whose automated
QA is the detected `test_command`; it has no preview command and therefore
no browser or native verification. This recognition phase is Expo-only:
mobile creation is unavailable until R2 (`create_project` refuses
`mobile_app` with `mobile_creation_unsupported`), and browser activation,
export readiness and native verification are outside this item. When
detection cannot qualify the repository, pass `project_kind: "mobile_app"`
(optionally `stack: "node"`) yourself; a supplied pick is authoritative
and preserved against later auto-detection. Picking the kind derives the
`test_command` QA default — a kind-derived default, not explicit QA
ownership; explicit QA ownership is a deliberate test-command choice in the
dashboard QA setup.

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 names
get_billing(). Otherwise next_step names the poll of
get_provisioning_status(project_id).

Input Schema

NameRequiredDescriptionDefault
stackNo
engineNo
project_kindNo
repo_full_nameYes
preview_commandNo
build_descriptionNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations (destructive=true, idempotent=false) by disclosing that re-import is replay-guarded, that re-importing a soft-deleted repo RESTORES the row in place, that restored queued refinement can delete tasks, and that the call is not idempotent end to end. It also documents the uniform denial semantics (never reveals whether a guessed repo exists) and the plan-allowance fallback where the project is created with the loop OFF and next_step points to get_billing(). Nothing here contradicts the annotations.

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

Conciseness3/5

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

The core purpose and routing sentence are correctly front-loaded, but the middle section balloons: the Expo config-file precedence list (app.config.ts, .mts, .cts, .mjs, .cjs, .js by filename presence, then app.config.json, then app.json) and the R2 roadmap caveats are implementation minutiae that crowd out decision-relevant content. Roughly half the text is a single niche case, which hurts scanning for the common path.

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 high-complexity, non-idempotent, destructive import tool, the definition covers authorization, error codes and retry, kind detection and override, credential prerequisites, restore semantics, and post-call next steps. An output schema exists, so the description is not obliged to explain the return payload, and what it does mention (already_exists=True) is a bonus rather than a gap.

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?

Schema description coverage is 0%, so the description carries the full burden and does: `repo_full_name` format ('owner/repo'), `engine`'s allowed values, default and credential prerequisite, `project_kind`'s full enum plus the cases where it is mandatory and the consequence of omitting it ('unknown' blocks the dev lane), `stack` axis, and the conditional requirement on `preview_command`. This is substantially more than the bare schema conveys.

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?

States a specific verb and resource ('Connect an EXISTING GitHub repo as a Keelen project') and immediately distinguishes it from the closest sibling: 'This is the counterpart of create_project: it is for a repo that already exists.' An agent can route between the two without opening either schema.

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?

Explicit about when to use and when not to (existing repo vs. scaffold), states the authorization precondition (same caller must have called list_github_repos within 10 minutes or hold a grant), and gives a concrete recovery path for the `repository_access_required` error: call list_github_repos again, then retry. It also names the sibling to use for post-import work (submit_request) and the follow-up polls.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.