BotKelp

Buy scaffold template

buy_scaffold_template

Same repo hand-off as get_scaffold_template — a private GitHub repo BotKelp owns and manages itself, plus a short-lived clone credential — but paid per call in USDC via the x402 protocol instead of a BotKelp account: no signup, no API key, callable by any agent with its own wallet. Call once without a payment to receive the price and payment requirements (HTTP 402-style, in the tool result's accepts field), then retry the same call with _meta["x402/payment"] set to a signed x402 payment matching those requirements. You are only charged if the call succeeds.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`components`	Yes	Component ids to include, e.g. ["nextjs-base", "tailwind", "supabase-client"].
`projectName`	No	Name used in package.json and templates.

Schema Changelog

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

Changed1 schema field changedSep 7, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
First observedSep 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Discloses the 402-style payment negotiation flow and the 'only charged if succeeds' guarantee, which is critical behavioral context. It does not fully describe the success result beyond repo hand-off, but the description is sufficiently transparent for the core transaction behavior.

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

Conciseness4/5

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

The description is longer than average but every sentence carries necessary payment-protocol or selection information. It front-loads the relationship to get_scaffold_template and then explains the payment flow without unrelated detail.

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?

Given there is no output schema, the description adequately explains the expected intermediate result (payment requirements in 'accepts') and the successful outcome (repo hand-off with clone credential). It also provides enough context to distinguish this tool from its sibling and to understand the x402 payment flow.

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?

The schema already documents both parameters with 100% coverage, including an example for components and a description for projectName. The description adds no additional parameter-level meaning beyond that already present in the schema, so the baseline score of 3 is appropriate.

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?

Clearly identifies the tool as a paid, per-call version of get_scaffold_template for handing off a private GitHub repo and clone credential. The verb 'buy' plus the explicit contrast with the free/sibling tool makes the purpose unambiguous.

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?

Provides explicit step-by-step usage: call once without payment to get the price and payment requirements in the 'accepts' field, then retry with the x402 payment in '_meta["x402/payment"]'. Also states that no signup or API key is needed, which is important selection guidance.

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

All BotKelp tools Inspect

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

Disambiguation5/5

Each tool has a clearly distinct purpose (e.g., apply vs. generate vs. verify vs. search), and the detailed descriptions remove ambiguity even for similar actions like generating, getting, and buying a scaffold.

Naming Consistency5/5

All tool names follow a consistent verb_object or verb_phrase pattern (e.g., create_project, search_components, verify_scaffold), making the API predictable and easy to navigate.

Tool Count5/5

With 11 tools, the set is well-scoped for a scaffold management service—covering project creation, component resolution, scaffold generation/retrieval/purchase, verification, updates, and issue reporting without feeling bloated or sparse.

Completeness4/5

The surface covers the core lifecycle (create, generate, apply, verify, update, report) well, but lacks explicit project deletion or update operations, which are common but not strictly required for the stated purpose.

Resources

Need Help?