Verified component catalog over remote MCP: agents pick ids and get a project that builds.
Scored across 15 tools
Each tool has a distinct purpose: getters retrieve data, setters modify configurations, purchase creates scaffolds, verify runs builds, and report files issues. The only near-overlaps are get/set pairs (e.g., get_adminpageset vs set_adminpageset), but these are clearly differentiated by verb. No tool appears to duplicate another's function.
All tool names follow a consistent verb_noun snake_case pattern: get_* for reads, set_* for writes, plus purchase_scaffold, report_issue, and verify_scaffold. The naming is uniform and predictable, making it easy for an agent to infer behavior from the name alone.
With 15 tools, the server covers a complex domain (account status, component catalog, scaffolds, site profiles, admin page sets, GitHub integration, and build verification). Each tool serves a distinct function in the workflow, and the count is within the well-scoped range for a specialized MCP server.
The surface covers the full lifecycle: purchase a scaffold, fetch it, verify it, manage profiles and admin pages, connect GitHub, and report issues. Minor gaps include no delete operations for projects, profiles, or admin page sets, and no direct update for components, but these are edge cases that agents can work around (e.g., recreate via set_*).
No params. Says whether you are signed in (authenticated) and account tools work (accountToolsReady). Never returns a key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the auth prerequisite ('requires a linked account (transport auth)') and what the returned data actually represents (file trees baked into a dedicated forked repo).
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, no filler, and the dual-mode behavior is front-loaded before the supporting detail about the forked repo and auth. Every clause carries information an agent needs.
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 one-parameter read tool with full schema coverage, no output schema, and annotations covering safety, the description supplies everything needed: both return shapes, the mode selector, the auth requirement, and the downstream relationship to purchase_scaffold.
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 single parameter's description already says 'omit to list set names instead', so the description largely restates the schema. It adds no format, casing, or matching semantics for the name value beyond what the schema provides, making the baseline 3 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?
The description names a specific verb and resource ('Lists this account's admin page set names') and gives the exact dual behavior — list names when name is omitted, return a set's files when name is passed. It also frames the resource concretely as the file trees that purchase_scaffold bakes into a forked repo, which separates it from sibling setters like set_adminpageset.
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 clearly states the condition that selects each mode (omit name to list, pass name to fetch) and ties the resource to purchase_scaffold's admin_page_set param, so the agent knows where this data flows. It does not explicitly name set_adminpageset as the mutating alternative or state when not to use this tool, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One component's source files, UNRENDERED (EJS markers, not build-ready): inspect only; use purchase_scaffold for real files. Free, 32/day, signed-in account.
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | Component id, or id@version, e.g. "supabase-client@2.0.0". |
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?
Annotations already cover readOnly/idempotent/openWorld, so the description adds the important non-obvious behavior: an unconnected account returns an installUrl, and granting access requires the GitHub App install tied to a signed-in account. It stops short of describing pagination or listing limits.
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 tight sentences, front-loaded with the core capability before the conditional remediation flow. No filler or repetition.
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?
With no output schema, the description does the necessary work by sketching the return shape (connection status vs. file list, plus installUrl when unconnected). Complete enough for correct invocation, though error or empty-repo behavior is unspecified.
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% and the single path parameter is already documented as 'Omit for connection status.' The description reinforces this dual-mode behavior but adds no syntax or format detail beyond the schema, so baseline 3 applies.
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 dual-mode purpose: report whether a GitHub repo is connected, or list files under a path in that repo. The verb+resource is unmistakable and clearly distinct from set_github among siblings.
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 mode selection (omit path for connection status; supply path to list files) and a prerequisite workflow (sign in with GitHub before installing). It does not explicitly name sibling alternatives like set_github, but the read-vs-write distinction is evident from the name pair.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Short usage index. Then search_components to pick ids.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is low. The description adds non-obvious context the annotations cannot: that no project_api_key argument is required, which removes a likely agent mistake.
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, zero waste. The primary purpose (what is listed and what fields come back) is front-loaded, with the downstream routing note second.
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?
With no output schema, the description compensates by enumerating the returned fields (id, name, description, repo, components, maintain state), and it covers the auth question. Nothing an agent needs to call this zero-parameter tool 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?
There are no input parameters, so the baseline is 4. The mention of 'projectid' is an output field used by a sibling tool, not a this-tool parameter, and it is described clearly enough.
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 ('Lists this account's saved scaffold projects') and enumerates the returned fields, so the agent knows exactly what it retrieves. It also distinguishes itself from get_scaffold by explaining the re-fetch path, so no sibling confusion remains.
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 routes the agent onward ('use the projectid with get_scaffold to re-fetch a scaffold'), giving clear follow-up context. It does not state explicit when-not-to-use conditions for this tool, but none are really needed for a zero-argument list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refetches a scaffold you purchased (fresh clone command), no extra credits. Credit-flow projects need Maintain on. Same site_profile/delivery options as purchase_scaffold.
| Name | Required | Description | Default |
|---|---|---|---|
| delivery | No | "clone" (default) or "inline". | |
| 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. |
Your site profiles (privacy, terms, cookies, licence, custom_field) as JSON. list: true for names, or siteprofilename for one; field filters. Use next.arguments when a purchase reply says incomplete: true.
| 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. |
Buys a CI-green starter repo for component ids (credits via your signed-in account, or x402). Returns a git clone command and projectid. Red builds are refused and not charged. delivery "inline" returns files instead (more tokens).
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Saved project metadata. | |
| delivery | No | "clone" (default) or "inline". | |
| maintain | No | Renewable repeat access (default true). | |
| components | Yes | Component ids, e.g. ["nextjs-base","tailwind"]. | |
| site_profile | No | true or a profile name: bake legal pages in. | |
| admin_page_set | No | Extra file-set name. | |
| template_files | No | Extra files: true, or [{name}|{source,dest}]. |
Report a catalog/code bug or request a component (files an issue on botkelp/components). Signed-in account, 10/day. No secrets.
| 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. |
Free. Compact catalog TSV: id, provides, requires, conflictsWith. Omit args for all.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Words to match, e.g. "auth stripe". | |
| detail | No | Add short descriptions. | |
| provides | No | Required capability tags. |
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?
Annotations already declare destructiveHint=true and idempotentHint=true; the description reinforces this by saying it 'fully replaces' a named set, which tells the agent existing content is overwritten. It adds the file-source detail but doesn't state permission requirements or what happens to files omitted from the new set.
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-loads the verb and resource, then adds two supporting sentences that earn their place by disambiguating from purchase_scaffold and clarifying the file-based nature. Slightly more context than strictly necessary, but nothing is wasted.
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?
With only two parameters, full schema coverage, and annotations carrying the safety profile, the description is nearly complete. It could say more about the replace semantics for omitted files and whether a prior set must exist, but nothing critical 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 both 'name' and 'files' (with example paths) are already documented in the schema. The description adds only the notion of 'one named set' and the multiple-sets-per-account note, which is contextual rather than syntactic. Baseline 3 applies when the schema does the heavy lifting.
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 ('Creates or fully replaces one named admin page set for this account') and distinguishes itself from the sibling get_adminpageset by scope. The added 'real file source (React/Next.js), not text config' clarifies what the resource actually is, which an agent could not infer from the name alone.
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 clear context for when this tool is relevant by contrasting it with purchase_scaffold (which bakes a set into a new repo), and notes an account may hold multiple named sets. It stops short of an explicit when-to-use/when-not statement or naming a preferred alternative for the replace case.
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?
Annotations declare destructiveHint=true and idempotentHint=true, but the description doesn't explain the destructive nature (dropping the repo connection), confirm idempotency, or clarify openWorld implications. It mentions 'disconnect: true drops the connection' which aligns with destructiveness, but lacks deeper context like permissions, reversibility, or rate limits.
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?
Reasonably concise but includes extraneous workflow details (purchase_scaffold template_files) that confuse the tool's own scope. Front-loads the core action, but the second sentence about purchase_scaffold is tangential.
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?
The tool is simple (1 param, no output schema), so the description covers the basic usage. However, it misses important behavioral aspects like authentication requirements, error conditions, or what happens on repeat calls, and the integration with siblings is only partially explained.
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 'disconnect' is fully described in the schema (coverage 100%). The description adds minimal extra meaning ('drops the connection'), which is consistent with the schema. Baseline 3 for high schema coverage.
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?
Clearly states it returns a GitHub App install URL for granting repo access and can disconnect. The purpose is understandable, though it's somewhat muddled by mixing in a workflow with purchase_scaffold. Not fully explicit about what the tool itself does versus surrounding steps.
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 a sequence: open URL, pick repo, approve, then run purchase_scaffold. Suggests signing in with GitHub first. However, it doesn't clearly distinguish when to use this tool versus get_github, and the guidance is tangled with another tool's invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn Maintain on/off for a project and/or rotate its project key. Off keeps existing clones; it stops future get_scaffold access.
| 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. |
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?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds merge semantics beyond those hints: omitted fields are preserved (or blank for a new profile) and custom_field is merged key-by-key, which tells the agent how partial updates behave.
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 sentences, front-loaded with the upsert action, then the update semantics, then the multi-profile context. No filler.
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?
With no output schema, a nested `field` object, and a destructive annotation, the description supplies the needed merge/partial-update behavior and notes that multiple named profiles can coexist. It leaves the destructive aspect implicit, but the practical calling guidance is complete.
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 real meaning: the partial-update contract for `field` and the key-by-key merge for custom_field go beyond the schema's generic 'omitted fields keep their current value' note.
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 pair (creates or updates) plus the resource (one named site profile) and scopes it to this account. An agent can distinguish it from the sibling get_siteprofile at a glance.
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 clear call guidance: pass only what changed, omitted fields retain saved values, and custom_field entries merge key-by-key. It does not explicitly say when to prefer this over get_siteprofile, but the read/write split is obvious from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remote npm install && npm run build of your edited files (send every file). Call with files -> WAIT + jobId; call again with jobId -> OK or FAIL with the error tail. Needs a purchased projectid.
| 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). |
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_scaffold1 field changedInput schema / properties / delivery / descriptionPrevious value: -"\"clone\" (default): git clone command. \"inline\": files in the reply. No git needed. More tokens."New value: +"\"clone\" (default) or \"inline\"."purchase_scaffold10 fields changedInput schema / properties / admin_page_set / descriptionPrevious value: -"Optional extra file-tree name (same overlay as template_files). Prefer site_profile / template_files."New value: +"Extra file-set name."Input schema / properties / components / descriptionPrevious value: -"Component ids to include, e.g. [\"nextjs-base\", \"tailwind\", \"supabase-client\"]."New value: +"Component ids, e.g. [\"nextjs-base\",\"tailwind\"]."Input schema / properties / delivery / descriptionPrevious value: -"\"clone\" (default): git clone command. \"inline\": files in the reply. No git needed. More tokens."New value: +"\"clone\" (default) or \"inline\"."Input schema / properties / maintain / descriptionPrevious value: -"Keep repeat access to this repo renewable. Defaults to true. Ignored for x402 (accountless) purchases."New value: +"Renewable repeat access (default true)."Input schema / properties / project / descriptionPrevious value: -"Project metadata to save alongside the purchased scaffold."New value: +"Saved project metadata."Input schema / properties / project / properties / description / descriptionPrevious value: -"Free-text description saved with the project."New value: +"Notes."Input schema / properties / project / properties / name / descriptionPrevious value: -"Your label for this project, shown in get_projects and in the purchase reply. Shared template repos keep a generic package name, so this is not written into package.json."New value: +"Your label."Input schema / properties / site_profile / descriptionPrevious value: -"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, …)."New value: +"true or a profile name: bake legal pages in."Input schema / properties / template_files / anyOfPrevious value: -[
- {
- "const": true,
- "type": "boolean"
- },
- {
- "items": {
- "properties": {
- "dest": {
- "description": "Destination in the generated project. Defaults to the file's stored path / source path.",
- "type": "string"
- },
- "name": {
- "description": "Saved dashboard template file name.",
- "type": "string"
- },
- "source": {
- "description": "Path in the connected GitHub repo, e.g. \"legal/gdpr.md\" or \"app/rules/page.tsx\".",
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "const": true,
+ "type": "boolean"
+ },
+ {
+ "items": {
+ "properties": {
+ "dest": {
+ "description": "Destination path.",
+ "type": "string"
+ },
+ "name": {
+ "description": "Saved file name.",
+ "type": "string"
+ },
+ "source": {
+ "description": "Path in connected repo.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+]Input schema / properties / template_files / descriptionPrevious value: -"true: every saved dashboard template file. Or a list of {name} and/or {source, dest} from the connected GitHub repo."New value: +"Extra files: true, or [{name}|{source,dest}]."search_componentspurchase_scaffold1 field changedInput schema / properties / project / properties / name / descriptionPrevious value: -"Name used for the project and in package.json."New value: +"Your label for this project, shown in get_projects and in the purchase reply. Shared template repos keep a generic package name, so this is not written into package.json."get_account_statusget_adminpageset2 fields changedInput schema / properties / account_api_keyRemoved value: -{
- "description": "BotKelp account key (starts with \"bk_live_\"). Required.",
- "type": "string"
-}Input schema / requiredRemoved value: -[
- "account_api_key"
-]get_component2 fields changedInput schema / properties / account_api_keyRemoved value: -{
- "description": "BotKelp account key (starts with \"bk_live_\"). Required.",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "account_api_key",
- "component"
-]New value: +[
+ "component"
+]get_github2 fields changedInput schema / properties / account_api_keyRemoved value: -{
- "description": "BotKelp account key (starts with \"bk_live_\").",
- "type": "string"
-}Input schema / requiredRemoved value: -[
- "account_api_key"
-]get_projects2 fields changedInput schema / properties / account_api_keyRemoved value: -{
- "description": "BotKelp account key (starts with \"bk_live_\"). Required.",
- "type": "string"
-}Input schema / requiredRemoved value: -[
- "account_api_key"
-]get_scaffold3 fields changedInput schema / properties / project_api_keyRemoved value: -{
- "description": "The project API key returned by purchase_scaffold (starts with \"sk_\"). Required.",
- "type": "string"
-}Input schema / properties / projectid / descriptionPrevious value: -"The project id from a previous purchase_scaffold result."New value: +"The project id from a previous purchase_scaffold result. Required — your project is resolved from your authenticated account."Input schema / requiredPrevious value: -[
- "project_api_key"
-]New value: +[
+ "projectid"
+]get_siteprofile2 fields changedInput schema / properties / account_api_keyRemoved value: -{
- "description": "BotKelp account key (starts with \"bk_live_\"). Required.",
- "type": "string"
-}Input schema / requiredRemoved value: -[
- "account_api_key"
-]purchase_scaffold1 field changedInput schema / properties / account_api_keyRemoved value: -{
- "description": "BotKelp account key (starts with \"bk_live_\"). Omit to pay via x402 instead.",
- "type": "string"
-}report_issue2 fields changedInput schema / properties / account_api_keyRemoved value: -{
- "description": "BotKelp account key (starts with \"bk_live_\"). Required.",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "account_api_key",
- "description"
-]New value: +[
+ "description"
+]set_adminpageset2 fields changedInput schema / properties / account_api_keyRemoved value: -{
- "description": "BotKelp account key (starts with \"bk_live_\"). Required.",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "account_api_key",
- "name",
- "files"
-]New value: +[
+ "name",
+ "files"
+]set_github2 fields changedInput schema / properties / account_api_keyRemoved value: -{
- "description": "BotKelp account key (starts with \"bk_live_\").",
- "type": "string"
-}Input schema / requiredRemoved value: -[
- "account_api_key"
-]set_projects5 fields changedInput schema / properties / account_api_keyRemoved value: -{
- "description": "BotKelp account key (starts with \"bk_live_\"). Required.",
- "type": "string"
-}Input schema / properties / project_api_keyRemoved value: -{
- "type": "string"
-}Input schema / properties / projectid / descriptionAdded value: +"The project id to change (from get_projects). Required — scoped to your authenticated account."Input schema / properties / rotate / descriptionPrevious value: -"If true, mints a new project_api_key and invalidates the old one."New value: +"If true, mints a new project key and invalidates the old one."Input schema / requiredPrevious value: -[
- "account_api_key"
-]New value: +[
+ "projectid"
+]set_siteprofile2 fields changedInput schema / properties / account_api_keyRemoved value: -{
- "description": "BotKelp account key (starts with \"bk_live_\"). Required.",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "account_api_key",
- "siteprofilename",
- "field"
-]New value: +[
+ "siteprofilename",
+ "field"
+]verify_scaffoldget_githubpurchase_scaffold3 fields changedInput schema / properties / admin_page_set / descriptionPrevious value: -"Name of this account's admin page set (see set_adminpageset) to bake into a dedicated forked repo. Omit for the ordinary shared repo."New value: +"Optional extra file-tree name (same overlay as template_files). Prefer site_profile / template_files."Input schema / properties / site_profile / descriptionPrevious value: -"false/omit: skip. true: attach this account's one site profile (errors if 0 or >1). A string: attach that named profile."New value: +"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, …)."Input schema / properties / template_filesAdded value: +{
+ "anyOf": [
+ {
+ "const": true,
+ "type": "boolean"
+ },
+ {
+ "items": {
+ "properties": {
+ "dest": {
+ "description": "Destination in the generated project. Defaults to the file's stored path / source path.",
+ "type": "string"
+ },
+ "name": {
+ "description": "Saved dashboard template file name.",
+ "type": "string"
+ },
+ "source": {
+ "description": "Path in the connected GitHub repo, e.g. \"legal/gdpr.md\" or \"app/rules/page.tsx\".",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ ],
+ "description": "true: every saved dashboard template file. Or a list of {name} and/or {source, dest} from the connected GitHub repo."
+}set_githubget_adminpageset1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_component1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_help1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_projects1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_scaffold1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_siteprofile1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"purchase_scaffold1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"report_issue1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"set_adminpageset1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"set_projects1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"set_siteprofile1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_scaffold2 fields changedInput schema / properties / site_profileAdded value: +{
+ "description": "false/omit: skip. true: attach this account's one site profile (errors if 0 or >1). A string: attach that named profile.",
+ "type": [
+ "boolean",
+ "string"
+ ]
+}Input schema / properties / siteprofileRemoved value: -{
- "type": [
- "boolean",
- "string"
- ]
-}verify_scaffoldget_adminpagesetget_scaffold1 field changedInput schema / properties / deliveryAdded value: +{
+ "description": "\"clone\" (default): git clone command. \"inline\": files in the reply. No git needed. More tokens.",
+ "enum": [
+ "clone",
+ "inline"
+ ],
+ "type": "string"
+}purchase_scaffold2 fields changedInput schema / properties / admin_page_setAdded value: +{
+ "description": "Name of this account's admin page set (see set_adminpageset) to bake into a dedicated forked repo. Omit for the ordinary shared repo.",
+ "type": "string"
+}Input schema / properties / deliveryAdded value: +{
+ "description": "\"clone\" (default): git clone command. \"inline\": files in the reply. No git needed. More tokens.",
+ "enum": [
+ "clone",
+ "inline"
+ ],
+ "type": "string"
+}set_adminpagesetapply_changes_to_repobuy_scaffold_templatecheck_component_updatescreate_projectgenerate_scaffoldget_admin_configget_componentget_helpget_projectsget_scaffoldget_scaffold_templateget_site_profileget_siteprofilelist_projectspurchase_scaffoldreport_issue13 fields changedInput schema / properties / account_api_keyAdded value: +{
+ "description": "BotKelp account key (starts with \"bk_live_\"). Required.",
+ "type": "string"
+}Input schema / properties / actualRemoved value: -{
- "description": "What actually happened (compiler error, missing file, etc.).",
- "type": "string"
-}Input schema / properties / bodyRemoved value: -{
- "description": "What is wrong or what you want. Include enough detail to reproduce. No secrets.",
- "type": "string"
-}Input schema / properties / componentIdRemoved value: -{
- "description": "Component id this is about, e.g. \"nextjs-base\".",
- "type": "string"
-}Input schema / properties / componentVersionRemoved value: -{
- "description": "Component version you generated with, if known.",
- "type": "string"
-}Input schema / properties / descriptionAdded value: +{
+ "description": "What is wrong or what you want. Include enough detail to reproduce. No secrets.",
+ "type": "string"
+}Input schema / properties / expectedRemoved value: -{
- "description": "What you expected to happen.",
- "type": "string"
-}Input schema / properties / kindRemoved value: -{
- "description": "bug (default), request (new component/capability), or docs.",
- "enum": [
- "bug",
- "request",
- "docs"
- ],
- "type": "string"
-}Input schema / properties / projectidAdded value: +{
+ "description": "Optional project id this report relates to.",
+ "type": "string"
+}Input schema / properties / reporterRemoved value: -{
- "description": "Optional agent or user label. No secrets.",
- "type": "string"
-}Input schema / properties / requestIdRemoved value: -{
- "description": "The requestId returned by generate_scaffold / get_scaffold_template / buy_scaffold_template / verify_scaffold.",
- "type": "string"
-}Input schema / properties / titleRemoved value: -{
- "description": "Short issue title, e.g. \"nextjs-base layout missing html lang\".",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "requestId",
- "title",
- "body"
-]New value: +[
+ "account_api_key",
+ "description"
+]resolve_componentssave_admin_configsearch_componentsset_projectsset_siteprofileverify_scaffold5 fields changedInput schema / properties / account_api_keyAdded value: +{
+ "type": "string"
+}Input schema / properties / envVariables / descriptionPrevious value: -"Env var names to write placeholder values for before building (typically generate_scaffold's `envVariables` output) — needed for components that read process.env at build time (e.g. a Supabase client)."New value: +"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)."Input schema / properties / files / descriptionRemoved value: -"The full project to verify — generate_scaffold's `files` output with your edits applied. Provide this to start a verification."Input schema / properties / jobIdRemoved value: -{
- "description": "A job id from a previous WAIT response. Provide this to check a verification already started.",
- "type": "string"
-}Input schema / properties / projectidAdded value: +{
+ "type": "string"
+}get_admin_configsave_admin_configgenerate_scaffold1 field changedInput schema / properties / get_site_profileAdded value: +{
+ "description": "If true, attach dashboard legal documents (privacy/terms/…) for this API key in the same result. They are not added to the generated file tree. Requires apiKey. If incomplete, call get_site_profile with next.arguments.cursor.",
+ "type": "boolean"
+}get_scaffold_template1 field changedInput schema / properties / get_site_profileAdded value: +{
+ "description": "If true, attach dashboard legal documents for this key in the same result. They are not written into the template repo. If incomplete, call get_site_profile with next.arguments.cursor.",
+ "type": "boolean"
+}get_site_profileapply_changes_to_repo2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / files / items / additionalPropertiesRemoved value: -falsebuy_scaffold_template1 field changedInput schema / additionalPropertiesRemoved value: -falsecheck_component_updates2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / componentPins / items / additionalPropertiesRemoved value: -falsecreate_project1 field changedInput schema / additionalPropertiesRemoved value: -falsegenerate_scaffold3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / components / items / anyOfPrevious 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"
- }
-]New value: +[
+ {
+ "description": "Component id, or id@version (e.g. \"supabase-client@2.0.0\").",
+ "type": "string"
+ },
+ {
+ "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"
+ }
+]Input schema / properties / stack / additionalPropertiesRemoved value: -falseget_scaffold_template1 field changedInput schema / additionalPropertiesRemoved value: -falselist_projects1 field changedInput schema / additionalPropertiesRemoved value: -falsereport_issue1 field changedInput schema / additionalPropertiesRemoved value: -falseresolve_components3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / components / items / anyOfPrevious 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"
- }
-]New value: +[
+ {
+ "description": "Component id, or id@version (e.g. \"supabase-client@2.0.0\").",
+ "type": "string"
+ },
+ {
+ "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"
+ }
+]Input schema / properties / stack / additionalPropertiesRemoved value: -falsesearch_components1 field changedInput schema / additionalPropertiesRemoved value: -falseverify_scaffold2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / files / items / additionalPropertiesRemoved value: -falsegenerate_scaffold5 fields changedInput schema / properties / allow_incompatibleAdded value: +{
+ "description": "Expert override. Returns the requested pin with a warning instead of blocking.",
+ "type": "boolean"
+}Input schema / properties / components / descriptionPrevious 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\"]."Input schema / properties / components / items / anyOfAdded 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"
+ }
+]Input schema / properties / components / items / typeRemoved value: -"string"Input schema / properties / stackAdded 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"
+}resolve_componentsreport_issueapply_changes_to_repobuy_scaffold_templatecheck_component_updatescreate_projectgenerate_scaffoldget_scaffold_templatelist_projectssearch_componentsverify_scaffoldMCP Server for an Agent Task Marketplace
Governed MCP: agent audit, provenance, deterministic checks, and receipt-backed FragGate execution.
Remote MCP for Android CLI agent build gate, structured receipts, audit logs, and reviewer-ready evi
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Add one secure layer between your agents and this server.
