list_projectsList the projects registered by this BotKelp account. Requires a BotKelp account key — never returns another account's projects.
| Name | Required | Description | Default |
|---|---|---|---|
| botKelpKey | Yes | BotKelp account key (starts with "bk_live_"). Required. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add meaningful behavioral context: authentication is required and the tool deliberately scopes results to the BotKelp account, never returning another account's projects. This goes beyond what the name alone conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, information-dense sentences. The core action is front-loaded, and the auth/privacy caveat follows naturally without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one parameter and no output schema, the description provides the essential context: what is listed, under what auth, and the privacy boundary. It does not detail response shape, but that gap is minor given the simplicity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter already documents its required status and prefix format. The description simply reuses the same concept without adding much new parameter-level detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('projects registered by this BotKelp account'), clearly distinguishing this from siblings like create_project or generate_scaffold. It immediately identifies the scope of the list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: the tool lists the caller's own projects and requires an account key. However, it does not explicitly mention when to prefer this over alternatives or any exclusions, leaving usage guidance mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The nine tools split into clear functional clusters: registry discovery/update checks, project/repo management, and scaffold generation/delivery/verification. The three scaffold-delivery tools (generate_scaffold, get_scaffold_template, buy_scaffold_template) share a similar purpose, but their descriptions clearly separate inline files, account-backed private repos, and paid wallet-based access.
All tool names follow the same verb_noun snake_case pattern: apply_changes_to_repo, check_component_updates, create_project, generate_scaffold, get_scaffold_template, and so on. There are no camelCase or vague imperative names, so an agent can predict the action-object relationship across the whole server.
Nine tools is well within the ideal range, and each tool addresses a distinct part of the workflow: discovering components, generating and verifying scaffolds, obtaining managed templates, and managing linked repositories. No tool feels redundant or so out of place that the count becomes inappropriate.
The core workflow is covered: search components, check updates, generate and verify scaffolds, request a managed template, and apply changes to a linked repo via pull request. Minor lifecycle gaps remain, such as no way to delete or update a registered project, but agents can complete the main intended tasks.