BotKelp

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

Name	Required	Description
`project`	No	Project metadata to save alongside the purchased scaffold.
`delivery`	No	"clone" (default): git clone command. "inline": files in the reply. No git needed. More tokens.
`maintain`	No	Keep repeat access to this repo renewable. Defaults to true. Ignored for x402 (accountless) purchases.
`components`	Yes	Component ids to include, e.g. ["nextjs-base", "tailwind", "supabase-client"].
`site_profile`	No	false/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_set`	No	Optional extra file-tree name (same overlay as template_files). Prefer site_profile / template_files.
`template_files`	No	true: 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.

First observedOct 1, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so richly: repo is owned by BotKelp not the user, credential is short-lived and single-repo-scoped, a persistent projectid is returned, repeat requests reuse the repo at no cost, and failed builds (red ci.yml) are never charged. Payment mechanics (credits vs x402, credential passed at transport not as an argument) are explicitly disclosed.

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

Conciseness3/5

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

Every clause carries information, so it is not padded, but it is delivered as one dense run-on paragraph mixing payment, delivery, profiles, and file overlays. The front-loaded purpose is good, yet the lack of structure makes it hard to scan for a single decision.

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?

For a 7-parameter, nested-schema, no-output-schema purchase tool, the description covers return values, billing edge cases, credential handling, and profile/template overlays. It is close to complete; only the exact shape of the returned repo location/credential payload is left implicit, which is acceptable absent an output schema.

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 baseline is 3, but the description adds real semantics beyond the schema: maintain defaults true and is ignored for x402, site_profile true vs named-string behavior, delivery 'inline' costs more tokens, and how template_files extra pages land in the clone. Only marginal gaps remain on admin_page_set.

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 opening sentence states a specific verb (requests a build), the input (component ids), and the resource (private GitHub repo owned by BotKelp, not the user). It also names related siblings (get_scaffold/get_projects/set_projects) so the agent can position it in the toolset without opening other schemas.

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?

It gives conditional guidance: use 'inline' only when no shell is available, call get_siteprofile with next.arguments if a profile is incomplete, and see set_projects/ADR 0025 for maintain. It does not give a crisp 'use this instead of X when Y' rule against the read-side siblings, so it falls short of a 5.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?