Skip to main content
Glama

Purchase scaffold

purchase_scaffold

Requests a build for the given component ids, backed by a private GitHub repo BotKelp owns and manages itself under its own org — never your account. Returns the repo's location, a short-lived single-repo-scoped clone credential, and a persistent projectid for later use with get_scaffold/get_projects/set_projects. Repeat requests for the same component combination reuse the same repo at no extra GitHub-side cost. A failed build (red ci.yml) is never charged. Payment: pay with linked BotKelp account credits (MCP OAuth 2.1 / Bearer bk_live_ at transport — never a tool argument), or omit account linkage and pay per-call in USDC via x402 (attach payment via the MCP call's _meta["x402/payment"] — no signup). maintain (default true, credit flow only) keeps this project's repeat access renewable — see ADR 0025 and set_projects. Pass site_profile: true (only your account's single profile) or a profile name to attach that named profile's documents in the same result; if incomplete, call get_siteprofile with next.arguments — there is no second unsolicited reply. delivery: "clone" (default) returns a git clone command; "inline" returns the files in the reply instead, for callers that can't run git — costs more tokens, use only when a shell isn't available. Extra pages land IN the clone (unique personal bk-* repo; shared tpl stays generic): site_profile true or a name bakes dashboard legal pages (privacy/terms/cookies) as Next.js routes; template_files true (all saved files) or [{name} | {source, dest}] pulls dashboard files or files from the connected GitHub repo.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectNoProject metadata to save alongside the purchased scaffold.
deliveryNo"clone" (default): git clone command. "inline": files in the reply. No git needed. More tokens.
maintainNoKeep repeat access to this repo renewable. Defaults to true. Ignored for x402 (accountless) purchases.
componentsYesComponent ids to include, e.g. ["nextjs-base", "tailwind", "supabase-client"].
site_profileNofalse/omit: skip. true: bake this account's one site profile into the clone (errors if 0 or >1). A string: bake that named profile (privacy, terms, cookies, …).
admin_page_setNoOptional extra file-tree name (same overlay as template_files). Prefer site_profile / template_files.
template_filesNotrue: every saved dashboard template file. Or a list of {name} and/or {source, dest} from the connected GitHub repo.

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?

Annotations declare a non-read-only open-world operation, and the description adds substantial behavioral context beyond them: private repo ownership, short-lived clone credential, persistent projectid, reuse of repos for repeat component combinations, no charge for failed builds, and payment handling details. It does not contradict annotations.

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 purpose is front-loaded and the dense operational detail is relevant for a complex purchase tool. However, the single long paragraph with many parentheticals and nested conditions makes it harder to scan than necessary.

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?

Given seven parameters, no output schema, and a complex payment/build flow, the description covers return values, build behavior, payment modes, and edge cases sufficiently for an agent to call the tool correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description still adds meaning beyond the schema in places, such as explaining that extra pages land in the clone, that shared templates stay generic, and that site_profile bakes dashboard legal pages, though some payment and maintain details overlap with schema 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?

Starts with a specific verb and resource: 'Requests a build for the given component ids.' It explains the backing GitHub repo ownership and return artifacts, and explicitly routes later use to get_scaffold/get_projects/set_projects, distinguishing it from sibling retrieval tools.

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 conditional guidance: use 'inline' only when a shell isn't available, use site_profile for the account's single or named profile, call get_siteprofile if incomplete, and choose credit versus x402 payment flows. These are concrete when/when-not and alternative-path instructions.

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.

Resources