Skip to main content
Glama

BotKelp

by io.github.aiscimi-code

Create project

create_project

Register a project: links a GitHub repo the agent will maintain a persistent, synced local clone for, so future tasks can branch off an up-to-date base without re-cloning. Requires a BotKelp account key — projects are private to the account that registers them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
repoUrlYesGitHub repo URL, e.g. https://github.com/owner/repo
baseBranchNoDefaults to "main".
botKelpKeyYesBotKelp account key (starts with "bk_live_"). Required.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden itself. It discloses that a persistent, synced local clone will be maintained, that a BotKelp account key is required, and that projects are private to the registering account. It does not cover idempotency, error cases, or response behavior, but the disclosed side effects are significant and useful.

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?

Two sentences deliver purpose, mechanism, rationale, prerequisite, and privacy in a compact, front-loaded way. Every clause earns its place, and there is no redundant restatement of the tool title.

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

Completeness4/5

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

The description is complete enough for an agent to decide when and how to invoke this tool: it defines the registration side effect, the auth requirement, and account-level privacy. It omits edge-case behavior such as duplicate registrations and return values, but those are not critical for basic selection and invocation.

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

Parameters3/5

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

Schema description coverage is 75%, so most parameters are already documented. The description adds little parameter-specific meaning, mostly restating that the botKelpKey is required. The 'name' parameter remains undocumented in both schema and description, though its purpose is fairly self-evident.

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 specific verb and resource: 'Register a project' and links it to a GitHub repo that will get a persistent, synced local clone. This clearly distinguishes it from sibling tools like list_projects and apply_changes_to_repo. It avoids tautology and explains the actual function.

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

Usage Guidelines4/5

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

The description gives clear context: use this when future tasks should branch off an up-to-date cloned base without re-cloning. It also notes prerequisites (BotKelp account key) and privacy scope, but it does not explicitly state when not to use it or name alternative tools for other scenarios.

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

All BotKelp 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.2/5.0
Disambiguation4/5

Most tools target clearly distinct actions: search/check are read-only registry operations, generate/get/buy are different scaffold delivery modes, and create/list/apply/verify handle project lifecycle. The main ambiguity is between get_scaffold_template and buy_scaffold_template, which share the same repo-handoff behavior and differ only in payment/account requirements; the descriptions are detailed enough to tell them apart, but an agent could still pick the wrong one without reading carefully.

Naming Consistency5/5

Every tool follows a consistent verb_noun snake_case pattern: search_components, create_project, generate_scaffold, verify_scaffold, apply_changes_to_repo, and so on. The verbs are specific and the nouns map cleanly to the resources being acted on, making the toolset predictable.

Tool Count5/5

Nine tools is well-scoped for a scaffolding and component-registry service. Each tool covers a meaningful part of the workflow—discovery, generation, delivery, verification, project registration, and repository updates—without redundancy or excessive granularity.

Completeness4/5

The core domain is well covered: component discovery, update checking, scaffold generation in three delivery modes, build verification, project registration, and applying changes to a repo. Minor gaps exist—there is no project deletion/unregistration, no way to fetch a single project's details beyond list_projects, and no direct update action after check_component_updates reports newer versions—but agents can work around these without major dead ends.

Resources