Remote HTTP MCP that generates verified Next.js component scaffolds with integrity stamps for Claude/Cursor agents. Connect at https://www.botkelp.com/mcp. Auth: MCP OAuth 2.1 at tools/call (or Bearer bk_live_ fallback); initialize/tools/list are open.
Scored across 15 tools
The get_/set_ pairs and distinct purposes (get_component vs purchase_scaffold vs get_scaffold vs verify_scaffold) are well-separated by the descriptions, and the buy-vs-re-fetch-vs-verify boundaries are spelled out. Minor overlap between get_help's catalog and get_component's files, and the account/key/transport-auth nuances could momentarily confuse, but overall each tool has a clear role.
Nearly all tools follow a consistent lowercase verb_noun pattern (get_account_status, purchase_scaffold, set_projects, verify_scaffold), with the get_/set_ pairing reinforcing the convention. Small deviations: compound nouns like adminpageset/siteprofile omit the internal underscore used elsewhere, and purchase_scaffold has no get_ counterpart.
15 tools is at the upper edge of the healthy range but justified by the breadth of the domain (purchase, re-fetch, verify, profiles, admin sets, github, projects). Each get/set pairing earns its place rather than padding, though it sits near the point where consolidation could help.
The surface covers the full lifecycle of buying, fetching, editing, and verifying scaffolds, plus profile/admin-set/github management. Minor gaps: no explicit delete for site profiles or admin page sets (only create/replace), and no project deletion, but these are workarounds rather than dead ends.
Reports whether your authenticated account has a BotKelp account_api_key linked (yes/no) and when it was last linked/rotated. Never returns the key itself. Use this to check whether key-gated tools will work before calling them. Takes no parameters — your identity comes from the MCP transport, not the call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that the key is never returned, the output shape (yes/no plus timestamp), and that identity is transport-derived. It implies read-only behavior through 'reports' but does not explicitly state absence of side effects, which is a minor gap.
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?
Four sentences, each earning its place: output definition, safety guarantee, when-to-use, and parameter clarification. The most important info is front-loaded in the first sentence, and no filler exists.
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 no-parameter status tool with no output schema, the description covers purpose, return contents, authentication behavior, and usage rationale. An agent can call it correctly and interpret its result without missing information.
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?
There are zero parameters and the empty schema is fully covered. The description goes beyond schema by stating 'Takes no parameters' and explaining why: identity comes from the MCP transport, not the call. This eliminates any confusion about why no parameters exist, exceeding the baseline for a 0-parameter tool.
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 ('reports') and resource (account status focused on BotKelp account_api_key linkage), plus the exact output (yes/no and last linked/rotated). It clearly differentiates from sibling tools, which handle projects, components, scaffold, or site profile, not account key status.
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?
Explicitly states when to use: 'Use this to check whether key-gated tools will work before calling them.' Also clarifies no parameters are needed and identity comes from the MCP transport, guiding the agent's invocation behavior. This is strong, actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists this account's admin page set names (omit name), or returns one set's exact files (pass name). These are the file trees purchase_scaffold's admin_page_set param bakes into a dedicated forked repo. Requires a linked account (transport auth).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The set to fetch. Omit to list this account's set names instead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses dual-mode behavior, an auth prerequisite (linked account via transport auth), and the downstream meaning of the data. It omits error/empty behavior, but core behavioral traits are covered.
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?
Three dense sentences with the dual-mode behavior front-loaded and zero filler. Every sentence adds routing, data meaning, or a prerequisite.
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 no-annotation, single-param, no-output-schema tool, it supplies purpose, mode behavior, data provenance, and auth requirements. Return shape is only loosely sketched ('exact files'), a minor gap given no output schema exists.
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 coverage is 100%, so the schema already documents the single name parameter and its omit-to-list semantics. The description reinforces this but adds no syntax or format detail beyond the schema, matching the baseline for fully-covered schemas.
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?
States a specific verb+resource (lists admin page set names / returns a set's exact files) with dual-mode scope. It also distinguishes itself from siblings by naming purchase_scaffold and explaining the relationship via the admin_page_set param.
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?
Explicitly tells the agent when to omit name (list set names) versus pass name (get one set's files). Context for broader usage is given via the purchase_scaffold reference, though the sibling set_adminpageset is not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the exact, unrendered source files for one catalog component — the same files a purchased scaffold would include for it. Use this to inspect or compare a component before buying a scaffold. Free, but rate-limited to 32 calls/day per account. Requires a registered account key (no credits are spent). IMPORTANT: files contain raw EJS template markers (e.g. <%= projectName %>, <% ... %>) and are NOT build-ready. Do not copy get_component output directly into a project. Use purchase_scaffold or generate_scaffold for rendered, build-ready files.
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | Component id, or id@version, e.g. "supabase-client@2.0.0". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does so thoroughly: free but rate-limited to 32 calls/day, requires a registered account key, spends no credits, and crucially warns that output contains raw EJS markers and is not build-ready. This gives the agent significant behavioral context beyond a simple read operation.
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?
The description is dense but efficient. Each sentence earns its place: primary result, usage rationale, cost/rate limits, auth requirement, and the critical build-readiness caveat. The important warning is capitalized and near the end, while the core purpose is front-loaded.
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 single-parameter read tool with no output schema, the description covers everything an agent needs: what the tool returns, why to use it, limitations, authentication requirements, and how it differs from build-ready alternatives. Nothing essential is missing for correct selection and invocation.
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 schema already documents the component parameter with a version example. The description adds the concept of 'exact, unrendered source files' but does not add version syntax or formatting details beyond the schema. 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?
States a specific verb and resource: 'Returns the exact, unrendered source files for one catalog component.' It also distinguishes itself from sibling/related tools by framing its purpose as inspecting or comparing before purchase, which clearly separates it from get_scaffold, purchase_scaffold, and generate_scaffold.
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?
Explicitly tells the agent when to use it ('Use this to inspect or compare a component before buying a scaffold') and when not to ('Do not copy get_component output directly into a project. Use purchase_scaffold or generate_scaffold for rendered, build-ready files.'). This is direct, actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows whether this account has a GitHub repo connected, or lists files under a path in that repo. If not connected, the result includes installUrl — open it (GitHub App) to grant read access to one repo. Sign in on botkelp.com with GitHub first so the install is tied to your account.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Folder or file in the connected repo to list. Omit for connection status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns an installUrl when not connected, requires prior sign-in on botkelp.com, and implies a read-only operation (no side effects mentioned). It does not cover edge cases like invalid paths or rate limits, but the core behavioral traits are transparent.
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?
The description is three sentences, front-loaded with the core purpose, then the conditional behavior, then the prerequisite. Every sentence adds necessary information with no fluff. It is efficient and well organized.
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 tool with one optional parameter and no output schema, the description covers the main scenarios: connection status, file listing, and the install flow when not connected. It mentions the installUrl and the sign-in prerequisite. Missing details like error handling or pagination are not critical for such a tool. The presence of set_github as a sibling provides clear context for what this tool does not do.
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?
The single parameter 'path' is fully described in the schema (100% coverage) as 'Folder or file in the connected repo to list. Omit for connection status.' The description adds minimal extra context by restating 'lists files under a path', which does not go beyond the schema. Thus, the description adds little semantic value beyond what the schema already provides.
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 clear dual purpose: showing whether a GitHub repo is connected and optionally listing files under a given path. It also mentions the installUrl behavior, which differentiates it from other get_* tools that focus on different resources. The verb 'shows' and 'lists' are specific.
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 implies usage by stating what it does, but does not explicitly contrast it with alternatives like set_github. It does provide conditional guidance (if not connected, use installUrl) and a prerequisite (sign in first), but lacks explicit 'use this when' or 'use set_github when' instructions. The context is adequate but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, no API key. Usage + full component catalog as TSV (id, name, version, description, provides, requires, conflictsWith). Call this first. Prefer resource botkelp://catalog if your client supports it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly mentions 'Free, no API key' (covering authentication and cost) and describes the return format as a TSV catalog with exact column names. It stops short of declaring read-only behavior, but for a help/catalog tool that returns no content, 'get_help' strongly implies no side effects. Given a complex schema, this is a reasonably transparent description.
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?
The description is highly concise: four short sentences (or clauses) packing essential information: free/no key, output format, order-of-call, and a resource preference. It is front-loaded with the 'call first' instruction and the TSV specification, and there is no filler material.
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 zero-parameter tool with no output schema, the description supplies all necessary context: what it does (returns usage and catalog), how to invoke it (call first), and how to access the same data differently (botkelp://catalog). The TSV field list gives a full expectation of return structure. No critical information appears missing for a help entry point.
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?
The input schema has zero parameters, and the baseline for such a tool is 4. The description adds no parameter-specific meaning because there are none, correctly focusing instead on what the tool returns. No further parameter compensation is needed.
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 clearly identifies a specific purpose: providing usage instructions and the full component catalog in a defined TSV format with explicit fields (id, name, version, description, provides, requires, conflictsWith). It also positions itself as the entry point ('Call this first'), distinguishing it from sibling get_* tools that fetch individual components or settings.
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 contains explicit usage guidance: 'Call this first' tells the agent when to invoke the tool, and 'Prefer resource botkelp://catalog if your client supports it' gives an alternative route. However, it does not provide a when-not-to-use condition or explain when to use sibling get_component/get_projects tools instead, although the 'first' instruction implies those tools come after.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists this account's saved scaffold projects (id, name, description, repo, components, maintain state). Use the projectid with get_scaffold to re-fetch a scaffold — no project_api_key is needed as a tool argument.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation ('Lists') and adds a note about auth (no project_api_key needed). It doesn't describe side effects, but none are expected for a listing tool. This is adequate for the operation.
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 sentences, front-loaded with the primary purpose and return fields, followed by a usage hint. No wasted words; every sentence contributes value.
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 listing tool with no parameters and no output schema, the description specifies exactly what is returned (fields) and how to proceed with a project (via get_scaffold). There is no missing information needed to call the tool correctly.
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?
The tool has zero parameters, so the schema already covers everything vacuously. The description adds a clarifying note about the absence of a project_api_key, which reinforces the parameter list. This meets the baseline for no-parameter tools.
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 ('Lists'), resource ('saved scaffold projects'), and enumerates the returned fields (id, name, description, repo, components, maintain state). It clearly differentiates from sibling get_scaffold by explaining the relationship (use projectid with get_scaffold to re-fetch).
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?
Provides explicit context: it lists projects, and if you need to re-fetch a scaffold, use get_scaffold with the projectid. It also clarifies that no project_api_key is needed. It doesn't explicitly mention when not to use this tool (e.g., for modifications), but the purpose is clear enough to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-fetches a scaffold you already purchased via purchase_scaffold: a fresh clone credential and the current component versions, at no additional credit cost. Identify the project with projectid (resolved from your authenticated account). For a credit-flow project, this always requires an active Maintain subscription on it (see set_projects) — repos are shared by component combination, so this is always a repeat hand-off. An x402 (accountless) project has no Maintain gate. Pass site_profile the same way as purchase_scaffold to attach a named profile's documents in the same result. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| delivery | No | "clone" (default): git clone command. "inline": files in the reply. No git needed. More tokens. | |
| projectid | Yes | The project id from a previous purchase_scaffold result. Required — your project is resolved from your authenticated account. | |
| site_profile | No | false/omit: skip. true: attach this account's one site profile (errors if 0 or >1). A string: attach that named profile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does so thoroughly. It discloses the no-additional-credit-cost behavior, the Maintain subscription prerequisite, the x402 exception, the delivery-mode tradeoff, and the token cost of 'inline' delivery.
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?
The description is dense but every sentence earns its place: purpose, prerequisite, account-type exception, site_profile handling, and delivery options are all covered without fluff. The core purpose is front-loaded in the first sentence.
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?
Given three parameters, no output schema, and no annotations, this description is remarkably complete. It explains preconditions, authentication resolution, subscription gating, delivery results, and cross-reference to purchase_scaffold, leaving little ambiguity for an agent deciding whether and how to call the tool.
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 coverage is 100%, so the baseline is 3, but the description adds value beyond the schema: it explains the default delivery behavior, ties site_profile to purchase_scaffold semantics, and clarifies that inline delivery exists for callers that cannot run git. These additions go beyond simple restatement.
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 opens with a specific verb and resource: 'Re-fetches a scaffold you already purchased via purchase_scaffold,' immediately distinguishing it from purchase_scaffold and verify_scaffold. It also states exact outputs: a fresh clone credential and current component versions.
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: this tool is for already-purchased scaffolds, requires an active Maintain subscription on credit-flow projects, and has no Maintain gate for x402 projects. It references set_projects and purchase_scaffold, but does not explicitly state when-not-to-use it versus sibling alternatives such as verify_scaffold.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one or all of this account's named site profiles (privacy, terms, cookies, licence, custom_field) as JSON bodies + destination paths — not as files in a template repo. Pass list: true to see profile names, or siteprofilename to fetch one. field filters to specific categories (default: all). If the previous purchase_scaffold/get_scaffold result set incomplete: true, call this with next.arguments. There is no second unsolicited reply. Requires a linked account (transport auth).
| Name | Required | Description | Default |
|---|---|---|---|
| list | No | If true, return this account's profile names instead of a profile's content. | |
| field | No | "all" (default), or an array from: privacy, terms, cookies, license, custom_field. | |
| cursor | No | Resume token from a previous incomplete result, e.g. "doc:terms". | |
| siteprofilename | No | The profile to fetch. Required unless list: true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the load and does well: it discloses the auth prerequisite ('Requires a linked account (transport auth)'), the return shape (JSON bodies + destination paths, explicitly not repo files), cursor-based continuation from an incomplete result, and the unusual 'There is no second unsolicited reply' behavior. It stops short of describing rate limits or how large the full profile set can be.
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?
Front-loaded with the primary purpose and return format, then packed with usage rules. Dense and mostly waste-free, though the run-on flow across modes and the abrupt 'There is no second unsolicited reply' fragment cost a point.
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?
No output schema exists, but the description compensates by describing what is returned (JSON bodies plus destination paths) and covers auth, the list/fetch modes, and pagination recovery. Adequate for a read tool of this shape, though it doesn't state whether a profile name must exist beforehand.
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%, so a 3 is the baseline, but the description adds real operational meaning: it explains the interaction between list and siteprofilename, restates the field default, and shows cursor in context ('call this with next.arguments', 'incomplete: true') that the raw 'doc:terms' example in the schema does not convey.
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?
States a precise verb and resource ('Returns one or all of this account's named site profiles') and enumerates the content categories (privacy, terms, cookies, licence, custom_field), immediately separating it from file-based siblings by noting these come 'as JSON bodies + destination paths — not as files in a template repo'.
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?
Gives explicit selection rules for the mutually exclusive modes ('Pass list: true to see profile names, or siteprofilename to fetch one') and an explicit conditional trigger for a different workflow ('If the previous purchase_scaffold/get_scaffold result set incomplete: true, call this with next.arguments'), naming the sibling tools involved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
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.
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.
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.
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.
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.
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.
File a GitHub issue on https://github.com/botkelp/components/issues about generated or catalog code, or request a new component/docs change. Welcome — we want agents to report problems instead of silently papering over them. Requires a linked account (spam guard), rate-limited to 10 calls/day per account. projectid is optional context. Never include API keys or secrets in description.
| Name | Required | Description | Default |
|---|---|---|---|
| projectid | No | Optional project id this report relates to. | |
| description | Yes | What is wrong or what you want. Include enough detail to reproduce. No secrets. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses the linked-account requirement (spam guard), the hard rate limit of 10 calls/day per account, the optional nature of projectid, and a no-secrets rule. These are exactly the operational constraints an agent needs before invoking a write-style tool.
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?
Front-loaded with the action and destination, and every sentence carries real information (scope, motivation, auth, rate limit, secret warning). The motivational 'Welcome' clause is slightly chatty but still serves a routing purpose.
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 2-parameter, no-output-schema tool with no annotations, this covers destination, scope, auth prerequisite, rate limit, and sensitive-data handling. Nothing an agent needs in order to call it correctly is missing.
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%, so the schema already documents both parameters with reproduce-level detail and the 'No secrets' warning. The description echoes this ('projectid is optional context', 'Never include API keys or secrets') without adding syntax or format meaning, so the baseline 3 is correct.
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?
States a specific verb+resource (file a GitHub issue at a named URL) and bounds the scope to generated/catalog code problems or component/docs change requests. An agent can distinguish this from the read-only get_* siblings without opening any schema.
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?
Explicitly encourages use ('we want agents to report problems instead of silently papering over them'), giving clear context for when to reach for it. It does not name an alternative or state exclusions, so it falls short of the 5-level when/when-not/alternatives pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates or fully replaces one named admin page set for this account — real file source (React/Next.js), not text config. purchase_scaffold's admin_page_set param bakes a chosen set into a brand-new, dedicated repo. An account may keep more than one named set.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for this set, e.g. "default" or "acme-admin". | |
| files | Yes | The full set of files, e.g. [{ path: "app/admin/page.tsx", content: "..." }]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool creates or fully replaces a named set, indicating destructive behavior, and clarifies that it operates on real file source rather than text config. It also notes that multiple sets can coexist, avoiding the implication that all sets are overwritten. It does not mention permissions or error handling, but the core behavior is transparent.
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?
The description is three sentences with zero fluff. The main action is front-loaded ('Creates or fully replaces'), the contrast with purchase_scaffold is concise, and the multiple-set clarification is brief. Every sentence earns its place without redundancy.
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 two-parameter write tool with no output schema and no annotations, the description is quite complete. It explains the purpose, the destructive nature, the file type, and the relationship to purchase_scaffold. It does not mention permissions or return values, but these are not critical for a tool of this simplicity. The description provides enough context for correct invocation.
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 coverage is 100% (both name and files have descriptions), so the baseline is 3. The description adds meaning beyond the schema by clarifying that files are actual React/Next.js source code and that the operation fully replaces the set, which informs how the files array should be constructed. This extra context helps the agent understand the intent of the parameters.
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 clearly states a specific verb (creates/replaces), a specific resource (named admin page set), and the key differentiator (real file source, not text config). It also distinguishes from the sibling purchase_scaffold, which bakes a set into a new repo, and implies the read counterpart get_adminpageset. This leaves no ambiguity about what the tool does.
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 provides clear context for when to use this tool versus purchase_scaffold (baking into a new repo), and mentions that an account may keep multiple named sets, implying this is for managing sets independent of a repo. However, it does not explicitly state when to use get_adminpageset for reading, though that is implied by the set/get pairing. It gives enough context to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a GitHub App install URL so the user can grant BotKelp read access to one of their repos. Open the URL, pick a single repo, approve. Then purchase_scaffold template_files: [{ source: "app/legal/" }] copies those pages into the clone. disconnect: true drops the connection. Prefer signing in with GitHub on botkelp.com first.
| Name | Required | Description | Default |
|---|---|---|---|
| disconnect | No | true: drop the connected repo. Omit to mint a fresh install URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the read-only scope, the URL-approval flow, and the drop behavior of disconnect. It could add consequences of disconnect or whether reconnection requires a fresh URL, but the core behavioral traits are present.
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?
The main behavior is front-loaded, but the purchase_scaffold sentence is grammatically confusing and the overall structure mixes tool behavior, user instructions, and workflow context without clear separation. It is not bloated enough for a 2, but not crisp enough for a 4.
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 single-optional-param tool with no annotations and no output schema, the description covers the connect flow, disconnect behavior, and a follow-up scaffold step. It could mention verifying via get_github or the exact return shape, but an agent has enough context to invoke it correctly.
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 coverage is 100%, so the baseline is 3. The description repeats 'disconnect: true drops the connection' but adds no meaning beyond what the schema already states; the schema already documents the omit-to-mint-URL behavior.
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 concrete behavior: it returns a GitHub App install URL to grant read access to one repo, and 'disconnect: true drops the connection.' This maps clearly to the title. It does not explicitly differentiate itself from get_github, and the purchase_scaffold sentence adds noise, so it is not a full 5.
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 usable context: prefer signing in on botkelp.com first, and after approval use purchase_scaffold with the provided template_files. It does not enumerate exclusions or explicitly compare with get_github, but the workflow is clear enough for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turns Maintain on/off for one of this account's projects and/or rotates its project key. Identify the project with projectid (scoped to your authenticated account). Turning maintain off does not delete or revoke anything already cloned; it stops future repeat get_scaffold access after the current Maintain billing period.
| Name | Required | Description | Default |
|---|---|---|---|
| rotate | No | If true, mints a new project key and invalidates the old one. | |
| maintain | No | ||
| projectid | Yes | The project id to change (from get_projects). Required — scoped to your authenticated account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses one key behavioral consequence: turning maintain off does not delete or revoke already cloned content, only stops future repeat get_scaffold access after the current Maintain billing period. It does not elaborate on rotate behavior (e.g., immediate invalidation of old key) beyond what the schema already says, nor on other potential side effects, permissions, or reversibility. This is partial but useful transparency.
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?
The description is two sentences with no redundancy. The primary purpose is front-loaded ('Turns Maintain on/off...'), followed by a single important behavioral note. Every word contributes to understanding, making it highly efficient and well-structured.
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 set operation with three parameters and no output schema, the description covers the main points: what it does (maintain on/off, rotate key), how to identify the project (projectid scoped to account), and a key consequence (maintain off effect). It does not describe the exact response format or error conditions, but these are less critical for a mutation tool. It is sufficiently complete for an agent to use correctly without needing additional context.
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 67% (rotate and projectid have descriptions, maintain has none). The tool description compensates by explaining maintain's effect ('Turns Maintain on/off') and adding emphasis on projectid being scoped to the authenticated account. This adds meaning beyond the schema for the undocumented maintain parameter and clarifies usage context. It does not add much for rotate beyond what the schema already provides, but overall it adds value.
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 clearly states the tool's purpose: 'Turns Maintain on/off for one of this account's projects and/or rotates its project key.' This specifies the action (turning Maintain on/off, rotating key), the resource (a project of the authenticated account), and distinguishes it from sibling set_* tools (set_adminpageset, set_github, set_siteprofile) by naming the project resource explicitly.
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 on when to use the tool: to change Maintain status or rotate key for a specific project, identified by projectid scoped to the authenticated account. It also notes the consequence of turning maintain off (stops future get_scaffold access after billing period). However, it does not explicitly mention alternatives (e.g., use get_projects to list projects) or when not to use it, so it lacks an explicit when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates or updates one named site profile for this account. Fields omitted from field keep their current saved value (or blank, if the profile is new); pass only what changed. custom_field entries are merged key-by-key. An account may keep more than one named profile (e.g. one per brand/site).
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | Fields to change. Omitted fields keep their current value. | |
| siteprofilename | Yes | Name for this profile, e.g. "default" or "acme-co". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly reveals key behaviors: omitted fields retain current values, custom_field entries are merged key-by-key, and multiple named profiles are allowed. It does not cover errors, return values, or permissions, but the disclosed partial-update and merge semantics are critical for correct invocation.
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?
Three concise sentences, each carrying distinct value: the core action, the partial-update rule, and the merge/multiple-profile behavior. No fluff; information is front-loaded with the action first. It is efficiently structured and easy to scan.
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?
Given the nested field object and no output schema, the description covers the essential semantics needed to call the tool correctly: it explains how fields are applied, how custom_field merges, and that profiles are named and can be multiple. It does not mention error conditions or return values, but these are not critical for basic usage and are partly covered by the schema. Overall, it is complete enough for an agent to invoke it without confusion.
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 coverage is 100%, so the schema already documents both parameters. The description adds value by explaining the partial-update behavior ('Fields omitted... keep their current saved value') and the merge semantics for custom_field, which the schema does not mention. It also advises to 'pass only what changed,' going beyond the schema.
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 clearly states the action (creates or updates) and the resource (a named site profile for this account). It distinguishes itself from sibling setters like set_adminpageset or set_github by specifying the profile resource, though it does not explicitly name alternatives. The purpose is unambiguous and not a tautology.
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 implies usage: you use this tool when you need to create or update a named site profile, and it provides useful context about multiple profiles. However, it does not explicitly state when not to use it or mention alternatives (e.g., get_siteprofile for retrieval). Guidance is inferred rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a real npm install && npm run build against the given files on an isolated GitHub Actions runner and reports whether the project builds. Two-call protocol: pass files to start (returns WAIT + a jobId), then call again with that jobId to get the verdict (OK or FAIL). A full install and build usually takes one to two minutes. Requires the projectid of a project this account purchased via purchase_scaffold — attributes every build to a real customer. Use this after editing a get_scaffold result to check the edited project still builds, before handing it to the user. Send the full project — every file, not just the ones you changed. On FAIL, the response includes the tail of the failing step output (compiler/install errors). Fix the files and retry.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | The full project to verify — a scaffold's files with your edits applied. Omit when polling with jobId. | |
| jobId | No | Poll a previously started verification. Omit on the first call (pass files), pass the returned jobId on subsequent calls. | |
| projectid | Yes | The project id from a previous purchase_scaffold result — must be owned by this account. Required. | |
| envVariables | No | Env var names to write placeholder values for before building (typically get_component's `envVariables` output) — needed for components that read process.env at build time (e.g. a Supabase client). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a good job: it discloses real build execution on an isolated runner, the 1–2 minute delay, the two-call async protocol, the attribution to a purchased project, and the failure output tail. It doesn't mention rate limits or error cases like an invalid projectid, but the core behavioral profile is transparent.
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?
The description is dense but every sentence earns its place: purpose, async protocol, timing, prerequisite, usage context, full-project requirement, and failure behavior. It front-loads the core purpose and then layers necessary operational details without redundancy.
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?
Given there is no output schema and no annotations, the description is remarkably complete: it explains the WAIT + jobId response, the OK/FAIL verdict, the failure output tail, the polling call pattern, and the required project ownership. An agent has enough information to invoke and interpret the tool correctly.
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 coverage is 100%, so the schema already documents each parameter. The description adds real value beyond that by explaining the interaction between files and jobId (omit files when polling), requiring projectid from a prior purchase_scaffold result, and clarifying that envVariables are placeholder values needed for build-time process.env reads.
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 names a specific action ('Runs a real npm install && npm run build against the given files') and a clear outcome ('reports whether the project builds'). It also distinguishes itself from siblings by explicitly framing this as the check to run 'after editing a get_scaffold result', which differentiates it from get_scaffold and purchase_scaffold.
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 concrete when-to-use guidance: verify edited scaffolds 'before handing it to the user', and it explains the two-call protocol and the prerequisite (a project purchased via purchase_scaffold). It stops short of naming alternatives or stating explicit 'do not use when' conditions, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_account_statusget_adminpagesetget_componentget_githubget_helpget_projectsget_scaffoldget_siteprofilepurchase_scaffoldreport_issueset_adminpagesetset_githubset_projectsset_siteprofileverify_scaffold
Add one secure layer between your agents and this server.