Skip to main content
Glama

BotKelp

by app.vercel.agent-scaffold-mcp

Generate scaffold

generate_scaffold

Generate a project scaffold from catalog component ids. Pass stack (nextjs/react/…) so the registry can refuse incompatible pins — it never silently substitutes another version. Pin with "id@version" or { id, version }. Omit version to auto-select the best compatible release. Incompatible exact pins return COMPONENT_VERSION_INCOMPATIBLE plus alternatives and no files unless allow_incompatible is true. Component requires are resolved automatically. Omit apiKey for Local Mode. A successful result includes a requestId — pass it to report_issue if the output is wrong.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stackNoDetected project stack. When set, compatibility is a hard registry rule. Omit to receive latest (unconstrained).
apiKeyNoBotKelp API key (starts with "bk_live_"). Omit for Local Mode — free, unauthenticated, files-only generation.
componentsYesComponent ids to include, e.g. ["nextjs-base", "tailwind", "supabase-client@2.0.0"].
projectNameNoName used in package.json and templates.
allow_incompatibleNoExpert override. Returns the requested pin with a warning instead of blocking.

Schema Changelog

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

  1. Changed5 schema fields changed
    • addedInput schema / properties / allow_incompatible
      Added value: +{
+  "description": "Expert override. Returns the requested pin with a warning instead of blocking.",
+  "type": "boolean"
+}
    • changedInput schema / properties / components / description
      Previous value: -"Component ids to include, e.g. [\"nextjs-base\", \"tailwind\", \"supabase-client\"]."New value: +"Component ids to include, e.g. [\"nextjs-base\", \"tailwind\", \"supabase-client@2.0.0\"]."
    • addedInput schema / properties / components / items / anyOf
      Added value: +[
+  {
+    "description": "Component id, or id@version (e.g. \"supabase-client@2.0.0\").",
+    "type": "string"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "allow_incompatible": {
+        "description": "If true, return an incompatible pin with a warning instead of blocking.",
+        "type": "boolean"
+      },
+      "id": {
+        "description": "Catalog component id.",
+        "type": "string"
+      },
+      "version": {
+        "description": "Exact pin. Omit to auto-select the best compatible release.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "id"
+    ],
+    "type": "object"
+  }
+]
    • removedInput schema / properties / components / items / type
      Removed value: -"string"
    • addedInput schema / properties / stack
      Added value: +{
+  "additionalProperties": false,
+  "description": "Detected project stack. When set, compatibility is a hard registry rule. Omit to receive latest (unconstrained).",
+  "properties": {
+    "angular": {
+      "type": "string"
+    },
+    "django": {
+      "type": "string"
+    },
+    "dotnet": {
+      "type": "string"
+    },
+    "laravel": {
+      "type": "string"
+    },
+    "nextjs": {
+      "type": "string"
+    },
+    "node": {
+      "type": "string"
+    },
+    "php": {
+      "type": "string"
+    },
+    "python": {
+      "type": "string"
+    },
+    "react": {
+      "type": "string"
+    },
+    "supabase_ssr": {
+      "type": "string"
+    },
+    "svelte": {
+      "type": "string"
+    },
+    "typescript": {
+      "type": "string"
+    },
+    "vue": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries full responsibility. It discloses critical behaviors: never silently substitutes versions, returns COMPONENT_VERSION_INCOMPATIBLE with alternatives, auto-resolves requires, supports Local Mode, and includes a requestId for issue reporting. This is thorough and transparent.

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 a single dense paragraph with no wasted words. It front-loads the core purpose, then methodically covers pinning, error handling, requires resolution, Local Mode, and the requestId. Every sentence contributes actionable information.

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 tool with 5 parameters and nested objects, the description covers usage, error handling, Local Mode, and output context (requestId). It does not fully specify the return format, but it gives enough to call correctly, and there is no output schema to reference. The description is comprehensive for the complexity.

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 coverage is 100%, so baseline is 3, but the description adds substantial meaning: it explains the format for components (id@version or object), why stack is passed (compatibility), what omitting apiKey does, and how allow_incompatible works. It enriches each parameter beyond the schema's own descriptions.

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 action ('Generate a project scaffold') and the resource ('from catalog component ids'). It is specific about inputs and behavior, and it distinguishes itself from sibling tools like search_components or resolve_components by focusing on generation.

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 provides clear guidance on when to use this tool: it explains stack enforcement, pinning, auto-version selection, and Local Mode. It does not explicitly list alternative tools for other scenarios, but the context is sufficient for an agent to decide when this is the right tool.

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.3/5.0
Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources